In Debian, after cleaning the folder, the ls command and access to the file takes a very long time, what is the reason?

Question

linux

In Debian, after cleaning the tmp folder from php sessions, and there were about 15 million of them, the ls command and access to the file became very long.
The first opening of a file can take up to 3 seconds! in any other folder is fine. Even if you delete everything again, nothing changes.
Perhaps the problem will be solved by deleting the folder and creating a new one, but it's interesting for the future what to do with it.
Ps sessions are generally stored in the database BUT, they were periodically created until I set session.save_handler = user in the settings

***@***:~/tmp$ time ls ~/
email  etc  logs  mod-tmp  tmp  www

real	0m0.002s
user	0m0.000s
sys	0m0.000s
***@***:~/tmp$ time ls ~/tmp

real	0m0.202s
user	0m0.000s
sys	0m0.200s

Wasn't wasting any more time. I deleted the folder, the deletion took half an hour, there was only 1 of my test files in the folder. By inodes, it was clear that the changes were within units (one of the users deleted / added something). It will remain a mystery to me

Answer 1

Is the folder really empty? Maybe those files to which they had rights were deleted, but some remained? If the folder weighs a lot, millions of files, so the answer takes a long time? Are there hidden files?

Answer 2

run lsof on this directory to make sure no one is really holding it.

Answer 3

Removed all files from the folder. When checking, it was 100% empty, I checked it from under the root, there were no hidden files or any other files in the folder, only sessions.
I tried lsof in the morning, the output is empty,
I decided to look if no files were created overnight, wrote ls from a regular user, waited 5 minutes, and the result is zero, although judging by df -i no more than 1000 files were created overnight, I think most of them are user , i.e. I didn’t see the reason, iotop showed 99.98% on ls
An attempt to kill the process was unsuccessful, I couldn’t kill it under root either, Apache hung from the load on io, restarting it also failed, apparently it looks in the folder with sessions or because over load could not create any file.
Apache could start only by rebooting.
moved the folder, made a new one for the sessions, in the new one everything works fine
put ~/mod-tmp2$ time ls -1 | wc -l with low priority, the server does not hang, let's see if it counts what or not (it's already been thinking 20)
When I just started counting, before deleting, this method found me 15 million files, and now there are only 2 million on the server, so the reason for the stupor is incomprehensible Let's
continue trying to figure out what's wrong? Or do not torture yourself and you and try to kill the pack and forget about it, although I feel there will be a catch when it is removed)
update

~/mod-tmp2$ time ls -1 | wc -l
1

real	26m35.291s
user	0m0.008s
sys	0m6.348s

Answer 4

Silly assumption, but maybe the directory is mounted? That is, some kind of network ball is mounted in it?