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

[Ross Walker]

On Jan 25, 2010, at 6:41 AM, Noob Centos Admin  
<centos.admin at gmail.com> wrote:

> Hi,
>
>> 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.

Split the TEXT/BLOB data out of the primary table into tables of their  
own indexed to the primary table by it's key column.

>> 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.

Think about distributing the parts to different boxes as necessary.  
You can start with the DBMS which is the logical candidate.

>> 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.

On the DBMS backend, give it plenty of memory, good storage for the  
workload and good networking.

On the Apache/PHP side, look for a good DBMS inter-connect and some  
PHP caching module and of course enough CPU for the PHP code and  
network for Apache+DBMS inter-connect.

If you wanted to split it up even more you could look into some sort  
of PHP distributed cache/processing system and have PHP processed  
behind Apache.

-Ross