[CentOS] Centos/Linux Disk Caching, might be OT in some ways

Noob Centos Admin centos.admin at gmail.com
Mon Jan 25 11:41:03 UTC 2010


> 20 feilds or columns is really nothing. BUT That's dependant on the type
> of data being inserted.

20 was an arbitary number :)

> Ok so break the one table down create 2 or more, then you will have
> "Joins" & clustered indexes thus slowing you down more possibly.  That
> is greatly dependant on your select, delete, and update scripts.

That was the reason the original develop gave for having these massive
rows! Admittedly it is easier to read but when each row also contains
text/blob fields, they tend to grow rather big. Some users have been
complaining the server seems to be getting sluggish so I'm trying to
plan ahead and make changes before it becomes a real problem.

> Possibly very correct, but Nate is very correct on how you are accessing
> the DB ie direct i/o also.  Your fastest access come in optimized SPROCS
> and Triggers and TSQL.  Slam enough memory into the server and load it
> in memory.

It's an old server with all slots populated so adding memory is not an
option. I thought of doing an image and porting it into a VM on a
newer/faster machine. But then at the rate this client's usage
growing, I foresee that as simply delaying the inevitable.

> If speed is what your after why are you worried about VFS?
> CentOS does support Raw Disk Access (no filesystem).

To be honest, I don't really care about VFS since I didn't know it
existed until I started looking up Linux file/disk caching :D

So I assumed that was what PHP and DBMS like MySQL/Postgresql would be
working through. It made sense since they wouldn't need to worry about
what filesystem was really used.

More information about the CentOS mailing list