Tonight's Outtage

Status
Not open for further replies.

Scott Greczkowski

Welcome HOME!
Original poster
Staff member
HERE TO HELP YOU!
Cutting Edge
Sep 7, 2003
103,271
27,974
Newington, CT
As you might have noticed we were offline for about an hour tonight. The problem was with a corrupt cache file, which has since been repaired.

Sorry for the outtage.
 
Scott Greczkowski said:
The problem was with a corrupt cache file, which has since been repaired.
"In God we Trust, all others pay cache..."

(with apologies to Jean Shepherd...)

This has my curiosity piqued, though. I thought the whole idea of cache was to speed things up by moving frequently-accessed data into higher-speed storage. Was the corruption in memory or an actual file on a storage device? (I suppose it could be a RAMdisk, though...)
 
No vbulletin had me testing something because we are one of the few vBulletin sites operating on a 64 Bit server.

The thing we were testing was a new caching scheme which was supposed to speed up database access, and while it did speed things up a little it was not as good as I hoped it would be (and as you could see it was a little buggy) :)

I really need to optimize our server, as it is underused. We have 8 gig of ram yet are only using about 3 gig of it.

Here is a look at our TOP stats.
Code:
top - 21:55:50 up 1 day,  4:14,  1 user,  load average: 0.38, 0.68, 0.88
Tasks: 256 total,   2 running, 254 sleeping,   0 stopped,   0 zombie
Cpu(s):  9.1% us,  0.7% sy,  0.0% ni, 88.4% id,  1.7% wa,  0.0% hi,  0.1% si
Mem:   8112172k total,  5049144k used,  3063028k free,   226168k buffers
Swap:  2040244k total,      160k used,  2040084k free,  2409240k cached
 
I'm not a *nix guy (OpenVMS is more of my expertise), but does the OS cache disk I/O? You could bump up the disk cache in that case and use some of that 5GB to speed things up.

We were running DB servers ten years ago with 512MB - 1GB of RAM and the big deal then was being able to use RAM for the database areas. It was great for metadata and things that didn't change so much that you were constantly writing to the disk behind the in-memory areas. Some indices were loaded there, making for fast searches.
 
With that amount of RAM you have swap size is too big (2 GB), it will slow down some tasks switching - I would try to reduce swap size to minimum minimorum. Actually your system took 5 GB and left 3 GB free.
That's idea to use some RAM as virtual disk for indices will really speedup DBMS processes - you can take 2 GB for that pretty easy.
 
Last edited:
Status
Not open for further replies.

blue book, red book, stars?

Welcome Walter L to the satguys staff

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 1)