Semi dedicated linux server – trying to figure out reason for sluggish performance – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.
But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about linux, apache-2.2, mysql, centos, .
I have a managed semi-dedicated server running Centos and a LAMP setup with PHP 5.2.9. I’ve noticed over the past couple of months that HTTP requests are taking much longer and page loading speeds across a number of sites have slowed down considerably. There doesn’t appear to be any significant load on the server and I’ve checked this with the sysadmin support, who say there isn’t any obvious issue. However, there has been a definite deterioration of performance, consistently, for at least two months now – so I really need to try and figure out what’s going on and am hoping someone might be able to suggest possible causes. The server is at around 80% of its disk usage capacity, so maybe that could be impacting on things.
Any help or pointers greatly appreciated!
EDIT: I have eAccelerator enabled, Apache KeepAlives enabled, mysql config as below. I should also point out that the bulk of the loading time for web pages is making the connection to the server, not downloading the page content.
[mysqld] max_connections = 400 key_buffer = 16M myisam_sort_buffer_size = 32M join_buffer_size = 1M read_buffer_size = 1M sort_buffer_size = 2M table_cache = 1024 thread_cache_size = 286 interactive_timeout = 25 wait_timeout = 1000 connect_timeout = 10 max_allowed_packet = 16M max_connect_errors = 10 query_cache_limit = 1M query_cache_size = 16M query_cache_type = 1 tmp_table_size = 16M #skip-innodb [mysqld_safe] open_files_limit = 8192 [mysqldump] quick max_allowed_packet = 16M [myisamchk] key_buffer = 32M sort_buffer = 32M read_buffer = 16M write_buffer = 16M
There are a few things you can try to do to narrow down the source of the performance issue (assuming it is mainly one thing anyways):
- Create a small HTML file and test accessing it remotely. If there is a performance issue here it is either somewhere on the network link between the servers or the Apache configuration.
- Create a small PHP file that does something basic (like output numbers 1-100) to see if the issue may be on the PHP side.
- Create a test file that accesses the database in a trivial/simple query to check the basic database performance.
- Run some typical queries locally on the server in the mysql client. If they run slow locally they are going be to slow remotely too. Enabling the slow query log is also a good idea if you suspect database performance issues.
- If you suspect the increase in database size to be the issue try testing queries on several copies of the database/tables (small, medium and large). If your queries or indexing is poor then you’ll see query times increase rapidly as the number of records grow.
- Check the basic server status like memory (make sure you are not hitting the swap regularly), hard drive errors (smartctl), server load, CPU idle time, free space on all partitions (like /tmp), other processes eating up the CPU/memory (top), and the system logs for relevant errors.
- If none of the above reveals anything you can start with a page/query that you know performs poorly and work backwards removing things until the issue is isolated.
If you’re doing a lot of database lookups in your php apps you might review your indexed tables as well as running an optimization on the database(s). Also consider increasing the thread_concurrency, buffers and table_cache in mysql’s configuration.
You might stand to gain some speed increases by optimizing apache and php as well. For instance, make sure you have KeepAlives enabled in Apache and consider installing and activating mod_gzip if applicable. For php you may want to look into the eaccelerator module.
It’s propably the disk subsystem. It’s either shared with another host which slows down your system, or worse, it’s some kind of big over-the-network disk subsystem. In both cases the responsetime of the disk is seriously affected.
It’s a good idea to use real dedicated hardware in production environment.
If you want to test this, move documents and mysql databases to tmpfs and see what happens. It’s not everything as system still needs to load stuff from the root, but it’s a start.