processor affinity
Question: can two IDS instances on one QA box (8 CPUs, 6 CPUVPs, RedHat AS3, IDS 10.00.UC3) both use processor affinity? Art Kagel answered yes, but suggested that if the instances' peak periods don't overlap it may be better to let them share processors, using affinity mainly to separate IDS from other applications. Discussion then widened to whether affinity is worth it at all; Martin Fuerderer explained the cache/context-switch rationale, noted benefits are hardest to predict on a dedicated server and greatest where IDS competes with other workloads, and advised testing in your own environment. No single definitive recommendation emerged.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
I am running two instances on a QA server. Can I use processor affinity for both instances if they copy my production instance? Production has 8 processors and 6 virt cpus. RedHat AS3 Linux, IDS 10.00.UC3 Bob Roussey robert.roussey@spiritair.com
Yes you certainly can. However, take a look at likely usage patterns for the two instances. If their primary peak periods are disjoint from one another, then you may do better to let them share more processors than to restrict each instance to a smaller subset of processors. You could still use affinity to keep the servers to different processors than other applications though. Art S. Kagel ----- Original Message ----- From: Bob Roussey <robert.roussey@spiritair.com> At: 11/30 12:39 I am running two instances on a QA server. Can I use processor affinity for both instances if they copy my production instance? Production has 8 processors and 6 virt cpus. RedHat AS3 Linux, IDS 10.00.UC3 Bob Roussey robert.roussey@spiritair.com
On the topic of affinity, for a dedicated Solaris box with one install of IDS is processor affinity a good idea? Zev Berezin Date sent: Wed, 30 Nov 2005 13:20:02 -0500 (EST) To: ids@iiug.org From: "ART KAGEL, ...." <KAGEL@bloomberg.net> Subject: Re: processor affinity [6050] > Yes you certainly can. However, take a look at likely usage patterns for the > two instances. If their primary peak periods are disjoint from one another, > then you may do better to let them share more processors than to restrict each > instance to a smaller subset of processors. You could still use affinity to > keep the servers to different processors than other applications though. > > Art S. Kagel > ----- Original Message ----- > From: Bob Roussey <robert.roussey@spiritair.com> > At: 11/30 12:39 > > I am running two instances on a QA server. Can I use processor affinity for > both instances if they copy my production instance? Production has 8 processors > and 6 virt cpus. > > > RedHat AS3 Linux, IDS 10.00.UC3 > > > Bob Roussey > robert.roussey@spiritair.com
Hi, you can still see performance benefits, at least in theory. [ In general even in a machine with several CPUs you will have more processes running than there are CPUs. Therefore at some time processes have to give up CPU and let others run. When a particular process then gets the next turn to run again, this can be on a different CPU. All this may depend on the scheduling model that the OS uses (or that you have configured the OS to use). With such a switch of CPU, there are a couple of things involved. E.g. the new CPU's cache may need to be filled with the processes context, etc. and the old CPU's cache probably needs to be filled with a different processes context. This is additional work to be done, often referred to as context switch. The idea of affinity is to avoid such additional work by making sure that a certain process always runs on the same CPU. I.e. it will not migrate from one CPU to another CPU upon being scheduled for runtime. Ideally the process will always be able to run on that CPU, i.e. the CPU is dedicated for this sole process. ] Whether all this works out to a noticable performance benefit depends on some other factors. How many CPUs does the machine have vs. how many processes are running. How many process switches are actually happening, which is influenced by even other factors. As mentioned before, the actual scheduling model/method used by the OS also plays a role in this. With that I guess in practice you will only find out by trying/testing in your specific environment. With several CPUs and several CPUVPs configured in IDS, there will be several permutations of affinity configuration that will be of interest for testing. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management forum.subscriber@iiug.org wrote on 30.11.2005 21:27:04: > On the topic of affinity, for a dedicated Solaris box with one > install of IDS is processor affinity a good idea? > > Zev Berezin > > Date sent: Wed, 30 Nov 2005 13:20:02 -0500 (EST) > To: ids@iiug.org > From: "ART KAGEL, ...." <KAGEL@bloomberg.net> > Subject: Re: processor affinity [6050] > > > Yes you certainly can. However, take a look at likely usage patterns for the > > two instances. If their primary peak periods are disjoint from one another, > > then you may do better to let them share more processors than to restrict each > > instance to a smaller subset of processors. You could still use affinity to > > keep the servers to different processors than other applications though. > > > > Art S. Kagel > > ----- Original Message ----- > > From: Bob Roussey <robert.roussey@spiritair.com> > > At: 11/30 12:39 > > > > I am running two instances on a QA server. Can I use processor affinity for > > both instances if they copy my production instance? Production has 8 processors > > and 6 virt cpus. > > > > > > RedHat AS3 Linux, IDS 10.00.UC3 > > > > > > Bob Roussey > > robert.roussey@spiritair.com
Hello, would you agree that processor affinity is overestimated? I think there was the recommendation of configuring more CPUVPs than physical CPUs (on machines with fast processors). That seems a little bit contradictionary to the reasons for using CPU affinity, isn't it? Even if you have a dedicated database server I'm not sure if CPU affinity really helps to improve performance - has anyone seen that in real life? For mixed systems (multiple IDS instances or IDS and applications) I think CPU affinity not only doesn't help but it will even lower the overall performance. I would like to hear about real life installations that prove me wrong. Regards, Andreas > ------------------------------------------- SPAR Oesterreichische Warenhandels-AG Hauptzentrale Europastrasse 3 A - 5015 Salzburg Tel: +43 662 4470 24223 Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at ------------------------------------------- -----Urspr|ngliche Nachricht----- > Von: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org]Im > Auftrag von Martin Fuer.... > Gesendet: Donnerstag, 01. Dezember 2005 09:50 > An: ids@iiug.org > Betreff: Re: processor affinity [6056] > > > Hi, > > you can still see performance benefits, at least in theory. > > [ In general even in a machine with several CPUs you will > have more processes running than there are CPUs. Therefore > at some time processes have to give up CPU and let others > run. When a particular process then gets the next turn to run > again, this can be on a different CPU. All this may depend > on the scheduling model that the OS uses (or that you have > configured the OS to use). > > With such a switch of CPU, there are a couple of things involved. > E.g. the new CPU's cache may need to be filled with the > processes context, etc. and the old CPU's cache probably needs > to be filled with a different processes context. This is additional > work to be done, often referred to as context switch. > > The idea of affinity is to avoid such additional work by making > sure that a certain process always runs on the same CPU. I.e. > it will not migrate from one CPU to another CPU upon being > scheduled for runtime. Ideally the process will always be able > to run on that CPU, i.e. the CPU is dedicated for this sole > process. ] > > Whether all this works out to a noticable performance benefit > depends on some other factors. How many CPUs does the > machine have vs. how many processes are running. How many > process switches are actually happening, which is influenced > by even other factors. As mentioned before, the actual > scheduling model/method used by the OS also plays a role > in this. > > With that I guess in practice you will only find out by trying/testing > in your specific environment. With several CPUs and several > CPUVPs configured in IDS, there will be several permutations > of affinity configuration that will be of interest for testing. > > Regards, > Martin > -- > Martin Fuerderer > IBM Informix Development Munich, Germany > Information Management > > forum.subscriber@iiug.org wrote on 30.11.2005 21:27:04: > > On the topic of affinity, for a dedicated Solaris box with one > > install of IDS is processor affinity a good idea? > > > > Zev Berezin > > > > Date sent: Wed, 30 Nov 2005 13:20:02 -0500 (EST) > > To: ids@iiug.org > > From: "ART KAGEL, ...." <KAGEL@bloomberg.net> > > Subject: Re: processor affinity [6050] > > > > > Yes you certainly can. However, take a look at likely > usage patterns > for the > > > two instances. If their primary peak periods are > disjoint from one > another, > > > then you may do better to let them share more processors than to > restrict each > > > instance to a smaller subset of processors. You could still use > affinity to > > > keep the servers to different processors than other applications > though. > > > > > > Art S. Kagel > > > ----- Original Message ----- > > > From: Bob Roussey <robert.roussey@spiritair.com> > > > At: 11/30 12:39 > > > > > > I am running two instances on a QA server. Can I use processor > affinity for > > > both instances if they copy my production instance? > Production has 8 > processors > > > and 6 virt cpus. > > > > > > > > > RedHat AS3 Linux, IDS 10.00.UC3 > > > > > > > > > Bob Roussey > > > robert.roussey@spiritair.com
Hi, no, I don't agree. The problems are: a) Overestimated or not depends on the expectations. With right expectations it will not be overestimated. b) It is a statement that is too general. Effects depend on individual facts in a specific scenario. E.g. one more factor (of many) influencing performance gain is how busy the CPUVPs are. c) As I tried to point out, it is difficult to predict performance benefits. However, that is the case with other features as well. d) Certainly it is not a panacea. It is not like "You have performance problems ? Just use affinity and you'll be fine." e) A dedicated machine for IDS probably is not the scenario where affinity will bring most performance gain. That scenario probably is where lots of other things are also running (e.g. application). In such a scenario, there will be a much higher competition for CPU. Therefore there will be much more CPU context switches, and therefore I would expect a better return from affinity - for IDS itself. Whether that results in higher overall system performance again depends on other factors, e.g. how the other applications (running on the same machine) are implemented. As with all performance questions/problems the right thing to do probably is to first determine, where the bottle neck is. Then fix that in way without causing a new bottle neck elsewhere, with possibly even worse overall effects. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management "Andreas.KUTSCHE@spar.at" <andreas.kutsche@spar.at> wrote on 01.12.2005 12:28:04: > Hello, > > would you agree that processor affinity is overestimated? > > I think there was the recommendation of configuring more CPUVPs than > physical CPUs (on machines with fast processors). > That seems a little bit contradictionary to the reasons for using > CPU affinity, isn't it? > > Even if you have a dedicated database server I'm not sure if > CPU affinity really helps to improve performance - has anyone > seen that in real life? > For mixed systems (multiple IDS instances or IDS and applications) > I think CPU affinity not only doesn't help but it will even lower > the overall performance. > > I would like to hear about real life installations that prove > me wrong. > > Regards, > Andreas > > ------------------------------------------- > SPAR Oesterreichische Warenhandels-AG > Hauptzentrale > Europastrasse 3 > A - 5015 Salzburg > > Tel: +43 662 4470 24223 > Mobile: +43 664 6259575 > E-Mail: Andreas.KUTSCHE@spar.at > Internet: http://www.spar.at > ------------------------------------------- > -----Urspr|ngliche Nachricht----- > > > Von: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org]Im > > Auftrag von Martin Fuer.... > > Gesendet: Donnerstag, 01. Dezember 2005 09:50 > > An: ids@iiug.org > > Betreff: Re: processor affinity [6056] > > > > Hi, > > > > you can still see performance benefits, at least in theory. > > > > [ In general even in a machine with several CPUs you will > > have more processes running than there are CPUs. Therefore > > at some time processes have to give up CPU and let others > > run. When a particular process then gets the next turn to run > > again, this can be on a different CPU. All this may depend > > on the scheduling model that the OS uses (or that you have > > configured the OS to use). > > > > With such a switch of CPU, there are a couple of things involved. > > E.g. the new CPU's cache may need to be filled with the > > processes context, etc. and the old CPU's cache probably needs > > to be filled with a different processes context. This is additional > > work to be done, often referred to as context switch. > > > > The idea of affinity is to avoid such additional work by making > > sure that a certain process always runs on the same CPU. I.e. > > it will not migrate from one CPU to another CPU upon being > > scheduled for runtime. Ideally the process will always be able > > to run on that CPU, i.e. the CPU is dedicated for this sole > > process. ] > > > > Whether all this works out to a noticable performance benefit > > depends on some other factors. How many CPUs does the > > machine have vs. how many processes are running. How many > > process switches are actually happening, which is influenced > > by even other factors. As mentioned before, the actual > > scheduling model/method used by the OS also plays a role > > in this. > > > > With that I guess in practice you will only find out by trying/testing > > in your specific environment. With several CPUs and several > > CPUVPs configured in IDS, there will be several permutations > > of affinity configuration that will be of interest for testing. > > > > Regards, > > Martin > > -- > > Martin Fuerderer > > IBM Informix Development Munich, Germany > > Information Management > > > > forum.subscriber@iiug.org wrote on 30.11.2005 21:27:04: > > > On the topic of affinity, for a dedicated Solaris box with one > > > install of IDS is processor affinity a good idea? > > > > > > Zev Berezin > > > > > > Date sent: Wed, 30 Nov 2005 13:20:02 -0500 (EST) > > > To: ids@iiug.org > > > From: "ART KAGEL, ...." <KAGEL@bloomberg.net> > > > Subject: Re: processor affinity [6050] > > > > > > > Yes you certainly can. However, take a look at likely > > usage patterns > > for the > > > > two instances. If their primary peak periods are > > disjoint from one > > another, > > > > then you may do better to let them share more processors than to > > restrict each > > > > instance to a smaller subset of processors. You could still use > > affinity to > > > > keep the servers to different processors than other applications > > though. > > > > > > > > Art S. Kagel > > > > ----- Original Message ----- > > > > From: Bob Roussey <robert.roussey@spiritair.com> > > > > At: 11/30 12:39 > > > > > > > > I am running two instances on a QA server. Can I use processor > > affinity for > > > > both instances if they copy my production instance? > > Production has 8 > > processors > > > > and 6 virt cpus. > > > > > > > > > > > > RedHat AS3 Linux, IDS 10.00.UC3 > > > > > > > > > > > > Bob Roussey > > > > robert.roussey@spiritair.com