Concerning the post from FuBuJo <siteartisan@gmail.com> about Zope Zeo with reference to RedHat blowing up with Zope. I've been running Zope on RedHat and RedHat based OSs since 1999, always on Dells, and only found an issue with RedHat 8.0 when it came out (before RHEL existed) and the issue was due to the change in threading on the RedHat distro bu there was a fix for Zope in Zope's configuration. After RedHat 7.3 I started using Fedora until last year when false CPU hardware errors kept crashing the server. Had to move to CentOS (RedHat based) because at that time Dell only supported RedHat, CentOS and Suse. No errors after installing CentOS using Apache, Zeo, and Zope. Now I am making arrangements to move back to RedHat with RedHat Enterprise Linux 5.0 and I am curious/concerned to what issues you experienced with RedHat. From original post: "The equipment is high end DELLs (well as of 3 years ago) - all running FreeBSD (we tried Red Hat but it blows up - but thats another post)." Thanks, Thomas -- ==================================================================== Thomas McMillan Grant Bennett Appalachian State University Operations & Systems Analyst P O Box 32026 University Library Boone, North Carolina 28608 (828) 262 6587 "... using OpenOffice.org, and save them back to disk automatically, in MS Word format. They surf the Web, check e-mail, do instant messsaging, view YouTube videos, visit their Facebook pages, learn touch-typing skills and lots more. Our public library has been offering these Linux public stations for the past three years." - Phil Shapiro Linux Journal January 2008 Library Systems Help Desk: https://www.library.appstate.edu/help/ ====================================================================
Sorry I haven't been handling the system administration (I just 'code' the pages), and truthfully we tried it for about 3 weeks - and now are switching back. But certainly that isn't enough time to really root cause determine anything definitive. The behavior we found is that the python process running as the "Zeo Client" eventually takes up a large amount of resident memory (1.5 Gig or so), load average gets high (1.5 or so), and the end users start experiencing a very 'slow' experience. Even when traffic is removed from the box - you still get a large response time (>10s). This is Linux kernel 2.6.18-8.el5xen. This is actually the issue we are having on FreeBSD (version 5.3) but the resident memory and load remains 1/2 of the above - and when traffic is removed from the box - you can then get a reasonable response (< 10s). I know it's not very scientific. We have a 'support agreement' with RH, so we are heading that way. But because the existing ZEO Server runs FreeBSD - and we are having performance issues, we figured to put everything back to the same OS while we try to figure out the performance part. When we investigate migrating from FreeBSD to RH for "real" - I'll certainly update this list if any of our findings would be of interest to anyone else.
FuBuJo wrote at 2008-3-14 19:38 +0000:
... The behavior we found is that the python process running as the "Zeo Client" eventually takes up a large amount of resident memory (1.5 Gig or so), load average gets high (1.5 or so), and the end users start experiencing a very 'slow' experience.
Does your system start swapping? In this case, you need to take urgent counter measures: * provide more RAM * check your configuration that affect memory consumption. The "temporary storage" hosting the sessions is often misconfigured. If you put large amounts of data in your sessions, this may be a considerable memory hog. Maybe, you need to make your ZODB caches smaller or reduce the number of concurrent threads. * check whether your application contains memory leaks. Unfortunately, this is not easy.
Even when traffic is removed from the box - you still get a large response time (>10s). This is Linux kernel 2.6.18-8.el5xen.
Python sits on top of the C runtime memory allocation -- and this allocation does not support compaction. This means that the memory used in your program is likely to be scattered all over the process address space. Therefore, even with small load, you may face large response times when your system is unable to hold the (usally large) working set in memory. -- Dieter
participants (3)
-
Dieter Maurer -
FuBuJo -
Thomas Bennett