Simon Reber <s.re...@lcsys.ch> wrote: > Don't worry too much - I'll take a look at it with the application guys and > probably with the vendor of the XML DB. They probably already have an > answer for that.
Kernel 2.6 VM - JRE VM - Application objects/heap, three layers to consider. Years ago I could put all that together. Nowdays I've been doing too many other things. ;) > We have systat running on that server, but I don't see any peak in there, > except during backup window of the filesystem and XML DB! That's good. In fact, part of your read cache could be due to the prior backup. If Linux has the memory, it'll use it. ;) The following is usually safe to do on RHEL5+ (not RHEL4 though) to drop all read caches: # echo 3 > /proc/sys/vm/drop_caches Just know that even though nothing has to be flushed, dropping caches is not always instantaneous, depending on if they are huge pages or not (administrative overhead). > But both of them are only visible on the I/O information. Swap is not touched > at all Then the kernel literally is moving pages into swap because they are virtually unused. Probably happens after enough reads, and the kernel sees you hitting those disk areas more than the resident objects/data it's swapping out. This is all speculation, of course. > But I also saw that lots of data are being swapped after initial startup of > the application. > The interesting part is, that the process I mentioned earlier is the gui > Application which is supposed to be used for the XML DB Management Interesting. They put the data load in as part of the GUI? Or the GUI causes a data load? I assume the service is separate from the GUI? (although you never know as they might be some Windows coders, although they usually go .NET when they are ;) ). > I'll change the value of vm.swappiness to 1 and see what's happening > But as mentioned above the applications starts swapping right after > initialization > and even then, the server has enough free memory available. > So I think, that it's best to talk to the vendor about that ... JRE VMs change everything. Of that, I'm sure. > It's on my todo list to configure the server according the the give hardware > configuration - right now I did not have time for it and the customer did not > complain > never wake-up a sleeping dog ;-) Exactly. Linux VM is smart by default, even with tuneables set poorly. If you don't see impacts, then it's not worth fighting. > But I'll look at this too and will hopefully find some time soon to-do proper > tuning. > Thanks for your help and your suggestions and all the best, I'm just suggesting Best Common Practice (BCP) and plausible causes from symptoms, many from existing Red Hat documentation (and RH442). -- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith _______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
