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