The Linux Server instantly generates a massive number of session files to fill the hard disk. What can be done?

A wordpress website runs on Linux, but it is abnormal recently in the form of instantaneous generation of massive session files (more than 11 million) in the tmp directory, and 400% of the CPU in an instant, the hard disk is directly cracked (90 GB), resulting in many server downtime files until the ls and rm commands are used... A wordpress website runs on Linux, but it is abnormal recently.

The specific manifestation is:
The/tmp directory instantly generates a massive number of session files (more than 11 million), the CPU instantly reaches 400%, and the hard disk directly explodes (90 GB), resulting in server downtime.

Many files have not been reflected by the ls and rm commands.

This happens in both nginx and apache2 webservers, and in both Ubuntu and CentOS.

Because I am a newbie in this field, I don't understand many problems. I checked a lot of information but could not solve them.

I guess whether it is related to WP super cache, but this problem still exists after the plug-in is stopped.

I can't find the relevant information, so I 'd like to ask:
Is this instant generation of massive session files related to attacks on the server?
How can we prevent such problems?

PS. A problem still occurred when using nginx. The CPU usage of the php-fpm process is, but some information found to track the process has not been obtained.

What information should I find to study this problem?

Please kindly advise. Thank you!

Reply content:

A wordpress website runs on Linux, but it is abnormal recently.

The specific manifestation is:
The/tmp directory instantly generates a massive number of session files (more than 11 million), the CPU instantly reaches 400%, and the hard disk directly explodes (90 GB), resulting in server downtime.

Many files have not been reflected by the ls and rm commands.

This happens in both nginx and apache2 webservers, and in both Ubuntu and CentOS.

Because I am a newbie in this field, I don't understand many problems. I checked a lot of information but could not solve them.

I guess whether it is related to WP super cache, but this problem still exists after the plug-in is stopped.

I can't find the relevant information, so I 'd like to ask:
Is this instant generation of massive session files related to attacks on the server?
How can we prevent such problems?

PS. A problem still occurred when using nginx. The CPU usage of the php-fpm process is, but some information found to track the process has not been obtained.

What information should I find to study this problem?

Please kindly advise. Thank you!

It is best to check the traffic statistics and check whether there are so many visits. The million traffic is abnormal.
Check the location where the session is written in the program. Is there any logic problem that leads to circular writing.

Store sessions in memcached

Distributed session storage.

1. In php programs, do not use session as much as possible, and use cookies as much better as possible.
2. Programmers who write this php program must be Tom and abuse the session. We do not know that the session cost is very high.
3. Save the session to the/dev/shm directory.-You do not need to modify the php program for this configuration.

If it is difficult to configure the server, I can provide Remote Assistance for more communication. QQ 1, 41096834

1. split session files into multiple directories to avoid File System io problems caused by massive files in a single directory.
// Php. ini see http://php.net/manual/en/session.configuration.php#ini.session.save-path
Session. save_path = 3;/tmp

2. Set a scheduled task to regularly clean up session files that have exceeded one day
// Crontab
0 3 ***/usr/bin/find/tmp/session-type f-atime + 1-delete

3. Put the session in redis or memcached instead of the file system.

4. simply do not use the session and change it to cookie + cache. This requires specific programming implementation.

You can use
Find...-delete
Or
Find... | xargs rm-f

Or is it true that @ Wulin is right? Check the logic of the program first.