 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / Ingres Topics / September 2006stack_size 65536 in multiples ?
Hi everyone, I've been running some Ingres DBMS configurations (2.6 SP2 on HP-UX Itanium) with dbms stack_size set to 512000. The default stack_size is 65536. Does it harm not to use a multiple of 512000 ? Regards, Franky Hi Franky, I've never heard anyone say it has to be a multiple of 65536. But don't forget that each session in the server gets the allocation, ergo the total stack_size required by the server is connections * stack_size. How big is your per process stack size configured in the kernel? Martin Bowes > Hi everyone, > [quoted text clipped - 12 lines] > Info-ingres@cariboulake.com > http://mailman.cariboulake.com/mailman/listinfo.py/info-ingres Hi Martin, Thanks for the prompt reply. To what kernel parameter are you exactly referring ? Franky Martin, Do you mean these : maxssiz 8388608 Default Immed maxssiz_64bit 268435456 Default Immed Franky Hi Franky, > Do you mean these : > > maxssiz 8388608 Default Immed > maxssiz_64bit 268435456 Default Immed Yes. Marty Marty, So these are the actual kernel parameters. I assume this is the contraint to be met : number of sessions x stack_size < maxssiz_64bit (64-bit system) Right ? Hi Franky, > So these are the actual kernel parameters. > I assume this is the contraint to be met : > > number of sessions x stack_size < maxssiz_64bit (64-bit system) > > Right ? Yes Marty >Hi everyone, > [quoted text clipped - 3 lines] >The default stack_size is 65536. Does it harm not to use a multiple of >512000 ? As far as I know, it doesn't make the slightest difference whether the stack size is a multiple of anything. Karl I've used many different sizes in benchmarks (multiples and non-multiples of the default) and never had a problem. I was looking at both performance and memory utilization (due to possible "wasted" memory from memory alignment) and never noticed anything significant from either perspective. The actual value does not seem to matter that much (assuming that it is "big enough"). The only benefit that I have seen is with stack overflows and SEGVs. In those cases it is either large enough or it isn't. At one site (32 bit OS) I needed to go to 600K, but usually it is half that or less amount. I haven't run into problems on 64 bit systems using the default. Are you seeing problems, or just trying something new? Chip Nickolett (ChipN@Comp-Soln.com) US - Comprehensive Solutions www.Comp-Soln.com UK - Comprehensive Solutions International www.Comp-Soln.co.uk FYI I raised a call earlier this year after some crystalreports SQL made the dbms go haywire, and we were advised by Ingres Corp that the DBMS stack_size should be a multiple of 65536. Steve > Hi everyone, > [quoted text clipped - 7 lines] > > Franky > FYI > I raised a call earlier this year after some crystalreports SQL made > the dbms go haywire, and we were advised by Ingres Corp that > the DBMS stack_size should be a multiple of 65536. I've certainly never heard that advice before, so until someone from tech support steps forward with a compelling rebuttal of Karl and Chip, I say that's a brand-new superstition in the making. If it's not nonsense ity should be handled by the crs file. The config parameter should be the number of 64kb blocks you want, not the number of bytes. Roy Hi Steve, That's why I am openening this thread. Yes, I also got an advice for using the multiple of 65.. . My probleem is that a usermod is hanging on a large table (AdvIng26SP2 on HP-UX ia64). All CPU resources are being taken by the usermod, and nobody can make another connection to the database.The initial advise was to use that multiple. Anyway, it did not solve the problem. Was yours solved that way ? Franky Hi Franky, Our prob was different, a big bit of SQL was failing with 'consistency check' when really it was running out of opf_memory. Ingres Corp looked at our config.dat and made the recommendation that the stack_size be increased, and said it should be a multiple of 65... We were running Ing 2.6 patch 9xxx on AIX 5.2 WRT your prob, can anyone else run the usermod? Is there any activity in the Ingres sort work area? What does IPM think the session is doing? Steve > Hi Steve, > [quoted text clipped - 7 lines] > > Franky >Hi Franky, >Our prob was different, a big bit of SQL was failing with >'consistency check' when really it was running out of >opf_memory. Ingres Corp looked at our config.dat and >made the recommendation that the stack_size be increased, >and said it should be a multiple of 65... The stack_size value is internally rounded up to a multiple of Ingres's "memory page size" , which is typically 4 or 8 K (and has little or nothing to do with any OS or architectural page size). I can't think of any benefit that rounding the stack size to a larger multiple might have. I'm inclined to think that the multiple of 64K thing is a bit of escaped superstition. Karl > >Hi Franky, > >Our prob was different, a big bit of SQL was failing with [quoted text clipped - 11 lines] > > Karl I agree. I had hoped to jump into the code and find the true answer but haven't had a chance to yet. I would think that it could be found during initial memory allocation - and would expect to see what Karl mentioned WRT rounding. The same thing is done with HASH tables and elsewhere, so I would really doubt that there would be problems using something that is not a multiple of 64K. The product is just too good to let something that simple break it. Chip ----- Original Message ----- Subject: [Info-ingres] Re: stack_size 65536 in multiples ? Err.. is it a big deal to just use a setting which is a 64K multiple? whether it's needed or not? As I recall, all that ingres does with this is to allocate a memory block large enough to accomodate all the session stacks. Each session is set up with it's stack pointer set to the correct position with the memory block. The only proviso I can remember (I haven't looked at this code for 12 years or so) is that the start of each stack must be situated on a word boundary and the code always makes sure the stacks are set correctly. If it were a big deal we'd probably have heard more about this years ago.. Paul Steve, I'd rather not introduce a new topic in this thread, but I can tell you a little more on the underlying problem. This happens when running the usermod : - the usermod starts executing the modify part on all tables but when it comes at the largest table (btree, many indexes) it starts taking all cpu (2) resources - at that time, the usermod stays in that situation (looping ?) using up all CPU and nobody can start a new session (starvation of iigcn?), even ipm hangs at the entry screen. The only thing for me to do is stopping the DBMS and restart. The funny thing is, when I afterwards drop the indexes of that table, I can run an individual modify on it finishing in a minute or 4. (Haven't tried it with indexes on yet). Anyway, Ingres is still looking at the issue. Thanks and regards, Franky |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.