Hi There's a thing you can do without disrupting your live cluster: try to make your development environment behave as closely as possible to the live one: PXE booting, 2.6.12 kernel, the likes. That would allow you to pinpoint the cause of the delay.
As a not-that-unrelated note: I understand that the current behaviour does not make much sense, so trying seemingly unrelated changes may lead you to a solution. Regards, DiegoG On Wednesday 04 March 2009 13:53:08 Derek Jones wrote: > Thanks again Lukasz. > > I could possibly investigate a FS change. I may be able to do that on a > limited basis. > > Problem is the production cluster is in use. I only have a certain clump > of grace periods to try this in - and then it has to be back the way it > was for multiM$ run processing - which being mostly SELECTS works well. > > That'd be true whatever I was changing... > > It's my development cluster that's working properly :-/ > > (!) > > I appreciate your suggestions tho' - always good to brainstorm thru' > things like this. Thankful. > > Kind regards > > Derek. > > Łukasz Jagiełło wrote: > > 2009/3/4 Derek Jones <[email protected]>: > >> Dear Lukasz, > >> > >> Thanks for the feedback. > >> > >> The FS is ext3 on both - with default block sizes. > > > > Strongly recommend check reiserfs. > > > >> I can't easily change the kernel on a production system - but I quite > >> appreciate the need to consider doing that if I had to - would be a > >> *big* change to make and I'd have to significantly plan to do that over > >> a collection of nodes. > > > > You said you got 2 clusters with 4 nodes. Change kernel at one node > > and see stats (cacti whatever), change FS and see stats. You can > > always sync that node with others. > > _______________________________________________ > Pgpool-general mailing list > [email protected] > http://pgfoundry.org/mailman/listinfo/pgpool-general _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
