Linux rocks
"Matthew Bowie" <[email protected]>
| Newsgroups | gmane.org.user-groups.nmlug |
|---|---|
| Message-ID | <[email protected]> |
Just thought I'd share some stuff that happened today. I just finished moving a LAMP(php/perl) stack over from a Pentium 4 3.4GHz/1GB RAM machine to a Pentium D 3.4/2GB RAM server. There was about 1.5GB of data in the MySQL database, and the client had a long running query that would aggregate much of it and display it on a page. It would normally take about 20-30 seconds to run. After moving over the scripts and database, the client tested the script, and as expected, it ran only slightly faster than it did on the other machine. Then the client wanted to run two instances of the script and see how the dual core system handled it. He started one, but before he could start the second, the first one was complete. He was pretty concerned, thinking that something much have been broken by the move, and that a cached copy was being served. How could a 30 second query be served in less than a second? A quick look at "free -m" showed that although the OS and LAMP stack was only taking 95MB of RAM, over 1.5GB was being used as cache. The majority of the normal 30 second query time was spent reading the data off disk. After the first query, Linux cached all the database files in RAM, so the next time the queries didn't have to pull anything off disk. That combined with MySQL's query cache made a big difference. The client was pretty impressed. The moral? Linux's aggressive file system caching is a good thing (usually). Linux doesn't let unused RAM sit around doing nothing, and sometimes it shows in a big way. So, if you can afford it, go for more RAM. -- Matthew Bowie Programmer/IT Consultant [email protected] _______________________________________________ NMLUG mailing list [email protected] http://lists.b9.com/cgi-bin/mailman/listinfo/nmlug