Posted by Vidus on August 27, 2010 at 2:47pm
Hi everyone,
I'm new to administering a group of sites my university runs for our professional writing program. We have a multi-site install for instructor courses, with two major folders containing sites. Each folder is a single install of Drupal, and has around 50 and 100 sites respectively.
We have VPS hosting through Liquidweb, and our Apache keeps getting bogged down and either restarting or needing restarting. Any ideas for optimizing the performance? I'm turning on caching on blocks, pages, optimizing CSS, etc, and hoping that helps, but the issue is troublesome.
Thanks,
Vidus
Comments
It could be any number of
It could be any number of things. Have you checked Apache's error logs to see if anything helpful appears there? Are you keeping an eye on RAM usage? What exactly do you mean by "bogged down" - is it just slow to respond, or does it not respond at all?
The Boise Drupal Guy!
re: server
What usually happens, is the processes get so high, our VPS provider kills our apache and restarts it. Or, it gets so high the server overloads and goes down. However, if we dont' get restarted by our VPS host, the site just creeps to a crawl and eventually comes back down. It does so on a pretty regular basis. When classes start at 30 after, it goes up. Then, it goes down slowly. But, we are trying to see if that spike is due to usage or something else.
We are getting processes tied to user profiles, or even just to registering that are hitting upward of 30% of cpu usage. Here is our process logs today:
Top Process %CPU 44.0 httpd [.org] [/site//user/register]
Top Process %CPU 41.0 httpd [.org] [/site//user]
Top Process %CPU 34.0 httpd [.org] [/site//materials]
Register is just site registration, materials is a view that lists terms in a taxonomy (in the example site, only 6 or 8 terms). This is what our host told us today:
It appears your sites have been maxing out the abilities of the VPS2 server
you are on. When your server tries to use more resources then it is allowed,
RAM for example, the parent server will stop whatever process is running that
is trying to use too much.
On the 25th your server had 190 processes stopped by the parent. On the 26th
it had them stopped 158 times. So far the parent has stopped services on your
server 52 times.
Have you been seeing an increase in traffic? It looks like there is a spike in
the bandwidth usage today.
-Vidus
Also, our VPS is: Processor
Also, our VPS is:
Processor #1 Vendor: AuthenticAMD
Processor #1 Name: Dual-Core AMD Opteron(tm) Processor 2212
Processor #1 speed: 488.443 MHz
Processor #1 cache size: 1024 KB
Processor #2 Vendor: AuthenticAMD
Processor #2 Name: Dual-Core AMD Opteron(tm) Processor 2212
Processor #2 speed: 488.443 MHz
Processor #2 cache size: 1024 KB
Processor #3 Vendor: AuthenticAMD
Processor #3 Name: Dual-Core AMD Opteron(tm) Processor 2212
Processor #3 speed: 488.443 MHz
Processor #3 cache size: 1024 KB
Processor #4 Vendor: AuthenticAMD
Processor #4 Name: Dual-Core AMD Opteron(tm) Processor 2212
Processor #4 speed: 488.443 MHz
Processor #4 cache size: 1024 KB
total used free shared buffers cached
Mem: 1048576 206076 842500
Filesystem Size Used Avail Use% Mounted on
/dev/vzfs 100G 44G 57G 44% /
simfs 100G 44G 57G 44% /tmp
simfs 100G 44G 57G 44% /var/tmp
Subscribing
I am in the process of setting up a multi-site install, so I would like to learn from this experience and provide my feedback once I am up and running.
JP
re: update
Talking with our host, the problem appears to be focused around our burst usage. We didn't have mySQL caching turned on for queries, but our main problem looking at logs is focused bursts of bandwidth and processing. Around :30 after we have courses starting on a regular basis, and that concentrated usage in multiple sections on multiple sites with multiple users is putting too great a demand on our VPS, and causing it to respond by killing Apache before it can destablize other servers on our main VPS server.
Our host suggested moving up to a cloud server option, which would be more power, memory, and storage for less than our current VPS. So we'd be moving form liquidweb's VPS to stormondemand's cloud solution (they are apparently a spin-off company of liquid web)
try disabling logging
The logging stuff takes a lot of Processes. Try shutting down all db logging and maybe even disable the logging modules.
I had a similar experience, but it was not a multi-site installation. The logging caused bursts of processes especially when accessing the admin pages.
I would also try getting some
I would also try getting some of the performance modules. Make sure you have performance settings for aggregation set so it's sending less files. Aggressive caching and/or http://drupal.org/project/boost. Has helped in a big way on our systems and we're running about the same size multisite for courses, student / staff services and public facing webpages. Totally agree on ditching the logging stuff.
Also, I know this happened to us once. We didn't have robots.txt configured in a way that made sense so crawlers were just rocking our server because it was finding some recursive paths. If there's a lot of Views (big ones) being run on a regular basis and they aren't cached effectively this can also cause major issues. Imagecache is another bog.
Sorry, just throwing out all options at this point :p. I know Yslow (http://developer.yahoo.com/yslow/) has also helped bc once we got eTags configured correctly the webserver was sending less redundant data and using cached copies once students got them the first time. http://drupal.org/project/network_manager is also used periodically to ensure settings across all sites in our multisite are standardized when it comes to performance / otherwise (yes a selfless plug to end things off ;) )
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
Thanks, I'll have to check
Thanks, I'll have to check and see what our current logging set-up is, and how we are doing with Y-slow. In theory, our robots.txt have a nice big go-away coded into them, but I'll need top peek at the apache logs and elsewhere to see if they are doing their job.
Thanks to everyone who gave
Thanks to everyone who gave me advice. We put quite a bit of it into practice, and turned on APC, and things are working much better now.