Thank you!

Suzanne — Wed, 02 Jan 2002 17:40:38 +0000

Thanks, Wil. I'll pass that on to the team. I think they suggested something similar, which is great. It's really good to have independent confirmation of a plan of action.

It's been a nightmare for this client, so I'm glad it's looking like it's resolvable.

Suzanne

Wil — Wed, 02 Jan 2002 09:59:07 +0000

Write a small script, ran by cron every day or two to GZIP your old log files, and maybe move them to a seperate partition (hell, even FTP them to another machine!) which should free up disk space. Won't do much for your memory though.

I would go with the looking into how effective are the SQL calls to your database server, especially if the connections aren't terminated. Check in the config files to time out connections that have been opened for more than 15 seconds (or maybe a little longer if you're doing complex calls on a busy server), this might help you catch the last of these buggers.

Cheers

Suzanne — Tue, 01 Jan 2002 22:41:11 +0000

Thanks, Mark,

I think you're right. We have identified a number of problems that are making things problematic.

1. The logs haven't been pruned in six months. That's right, MONTHS worth of raw logs in one file. Understandably, this is affecting things.
2. Extra connections for no reason.
3. Sessions aren't being terminated

So we're going to address those issues and see if it aids anything. I haven't had to reboot the server in 8 days, but I have stopped and started httpd a few times. Hopefully ditching the logs daily (archiving) will address some of the highest concerns, then removing the extraneous bits.

If that doesn't solve the problems, I guess I'll have to try again!

I have a great team working on this now, thankfully, and won't have to learn how to be a sysadmin in my "spare" time.

Thank you for your responses, it really helps to get an idea of what could be going wrong so I don't get hoodwinked.

mairving — Tue, 01 Jan 2002 21:52:44 +0000

Suzanne, sorry I didn't respond sooner. Been doing the Christmas thing.

I would suspect that the problem lies with EZPUB connecting to MySQL. You could try adding more RAM to satisfy your client but I think that the only thing that you would see is that there would be longer times between reboots. It is very unlikely that it could be number of users since that would only be a temp problem.

Suzanne — Thu, 27 Dec 2001 06:43:11 +0000

There are oodles of images on the site, so that fills up the logs quickly, plus the site it done in templates and includes, so there are a lot of "calls".

I guess the CMS is what's sucking up the memory.

Hm.

Anyone else have an idea? I'd like to be at least somewhat informed if I have to tell this client and the actual management team that they have to move to a new server.

Thanks!

Suzanne

nike_guy_man — Thu, 27 Dec 2001 06:08:22 +0000

Hello
I have a server of my own, and I run HTTPD as well as MySQL.
Thats basically my server software.
They only occupy about 10-15% of my 512 MB RAM.
When my traffic goes up a lot, my usage goes up to maybe 7-75%, depending on the # of connections at once.
I'd say for a high traffic site, a gig of ram should be fine, if you are running a lot of server side software, maybe 1.25 or 1.5 gigs.
This is simply my experience, so dont base your decision on me.
What kind of logs take up all the space??
My logs usually dont get too big....
What kind of server is this.