No, the website does not fall because he was tired. There are other, more obvious reasons for that, and now we have considered the three most likely of them. We assume that the site is “spinning” on a virtual server and if on a physical server, then everything is fine with hardware and there are no hardware faults.
Over the disk space/free inodes
The most obvious reason for the fall of the site. During the operation of network services like Apache, MySQL generate decent amounts of data – logs, temporary files, not to mention the user-uploaded data.
The service simply has nowhere to write further data and it “crashes”. Also, the reason for the fall of the same Apache can be an extremely large log size.
We recommend the following:
- In order not to regularly check disk space, install a monitoring service to automate this process. You can configure the same Zabbix or write a script on bash to monitor disk space.
- Configure logrotate to rotate and compress basic service log files. As a rule, after installing logrotate, all the necessary settings will already be in the configuration files, the admin will only have to make sure that the logrotate is started automatically. Additional info can be found in man logrotate.
Check disk space
Where is the disk space?
- Temporary files, look in /tmp. As a rule, from there you can delete all.
- Session files directory depends on the settings of the engine.
- Database to reduce the database size can be optimized. You can also run specific engine queries. For example, for WordPress the following query deletes comments with spam, which could significantly reduce the size of the database:
DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments)
- Mailboxes – few check mailboxes for standard mailboxes, but they can be spammed. They are usually stored in / var/mail. A few gigabytes of spam are quite real.
- Logs – view in /var/log. It is best to configure logrotate to rotate and compress the logs, but if some logs are too big and due to their service does not start, you can delete them.
- Backup – you may not have used the service to backup and set up the creation of backups using the system. In this case, check the backup directory and delete the oldest backups.
And now attention! Sometimes it is not the free space that ends, but the free number of inodes (i-node). The result is the same – the system cannot create the file and the site “crashes” due to the suspension of the network service. Where are the inodes? Some engines, such as Magento, generate too many session files (usually stored in / var/session, but it all depends on the engine settings). Such files are very small, they practically do not take up space, but they steal precious inodes. One of the tactics is to regularly clean the directory of sessions. The following script is added to cron:
cd /var/session for i in sess_*; do rm -fv $i; done
The disadvantage of this method is as follows:
- When you remove sessions erased all the information about the user, for example, its shopping cart and information about registration. The user comes to your store, selects the products, and places them in the basket. Then run a script to clean the basket was erased, so he still offers to re-enter.
- One of the site’s popularity was such that session very quickly ate all the available inodes. Had to run them clean almost every hour, otherwise, the website was not working properly. You know, every hour from all users, including managers, will be “thrown” from the site – it is not very good.
An alternative and more correct solution are to create another drive (or partition) with the file system ReiserFS. She does not Shine in performance but allows in a single block to store multiple files — while the block size is not filled. ReiserFS completely solved the problem with the inodes. The server is now quietly holding millions of files inode and cleaned /var/session is quite rare – on the server automatically cleans off and is done manually by the administrator once a month during regular server maintenance.
The lack of other resources for the website
In addition to disk space, do not forget about the memory and processor resources. The htop command will help here, which shows not only running processes but also consumed resources.
One of the reasons for the decline of the website – lack of resources, especially if we are talking about monstrous engines like Magento. They are sensitive not only to RAM but also to the number of cores.
