Re: Slow OS calls on one chip type - resolved!
"Neil Truby" <neil.truby@ardenta.com> wrote in message news:82pgrnFo58U1@mid.individual.net... > IDS 11.5FC6 on RHEL 5.3 > > Here's a starange one. When running SQL which interacts with OS to output > messages, it's very, very much slower at a new customer site than it is at > our own or others. The difference seems to be the AMD processors the > customer has (we have Intel) - the OS and IDS versions are identical. This turns out to have been caused by an RHEL kernel parameter setting being made too tight. Thanks to Uwe Weber from IBM, and several from c.d.i. but in particular Art Kagel, for their help in getting to the solution.
On 19 May, 18:39, "Neil Truby" <neil.tr...@ardenta.com> wrote: > "Neil Truby" <neil.tr...@ardenta.com> wrote in message > > news:82pgrnFo58U1@mid.individual.net... > > > IDS 11.5FC6 on RHEL 5.3 > > > Here's a starange one. When running SQL which interacts with OS to output > > messages, it's very, very much slower at a new customer site than it is at > > our own or others. The difference seems to be the AMD processors the > > customer has (we have Intel) - the OS and IDS versions are identical. > > This turns out to have been caused by an RHEL kernel parameter setting being > made too tight. > > Thanks to Uwe Weber from IBM, and several from c.d.i. but in particular Art > Kagel, for their help in getting to the solution. Which kernel setting?
<david@smooth1.co.uk> wrote in message news:b570f216-1b06-487a-bf71-598ca121de34@a16g2000vbr.googlegroups.com... On 19 May, 18:39, "Neil Truby" <neil.tr...@ardenta.com> wrote: > "Neil Truby" <neil.tr...@ardenta.com> wrote in message > > news:82pgrnFo58U1@mid.individual.net... > > > IDS 11.5FC6 on RHEL 5.3 > > > Here's a starange one. When running SQL which interacts with OS to > > output > > messages, it's very, very much slower at a new customer site than it is > > at > > our own or others. The difference seems to be the AMD processors the > > customer has (we have Intel) - the OS and IDS versions are identical. > > This turns out to have been caused by an RHEL kernel parameter setting > being > made too tight. > > Thanks to Uwe Weber from IBM, and several from c.d.i. but in particular > Art > Kagel, for their help in getting to the solution. >> Which kernel setting? A sysadmin writes ... Hi Neil I am not sure what parameter exactly was the problem but we commented out the following lines from /etc/security/limits.conf - which in the end left us with a default limits.conf file: # - stack - max stack size (KB) #* soft stack 32768 #* hard stack 32768 # - nofile - max number of open files #* soft nofile 90000 #* hard nofile 90000 # - nproc - max number of processes #* soft nproc 16384 #* hard nproc 16384 These were in place on recommendation from another vendor for other systems and were mistakenly applied to the database servers. The setting with the most impact in the case of a database I am thinking would be the number of open files.