Inode over load is crashing website

[kevinmc3]

Have my site on VPS with plenty of resources. However, it keeps hitting the inodes limit and crashing site. Hosting says my LOG folder has about 80% of these inodes (see ther update below). Can this folder or it contents be deleted?

Anything else to resolve this issue?


Thank you for contacting Hostgator Support, we recently found your VPS server hitting Inodes limits. We have temporarily increased the package limits on your server to prevent further service interruption, If you need any further assistance reducing the resource usage please let us know. The temporary limits will be reduced automatically after 72 hours.

siteis www.cvtreasures.com

[mc12345678]

Generally speaking, in a store that is not specifically logging things such as queries or every payment operation debug log, then there really should be no files generated and/or added to the logs folder. If there are files being added and their filename begins with myDebug, then the most recent of these should be reviewed to fix the problem(s) being identified.

Can the folder fill up? Yes. Can it degrade performance? Either it or the things causing the errors will do so. Best to figure out why so many files are being written.

[swguy]

As a practical matter, since there are now *so* many files in that folder, your best starting point would be to delete it and replace it with a fresh folder from a new download (the folder by default only contains 2 index files to prevent people from browsing it), and make sure it has the same permissions as before. Then watch it like a hawk as logs are generated, and resolve each one as it appears. In all likelihood, there will be a large number of duplicates, and possibly all of them will be duplicates.

[carlwhat]

As a practical matter, since there are now *so* many files in that folder, your best starting point would be to delete it and replace it with a fresh folder from a new download (the folder by default only contains 2 index files to prevent people from browsing it). Then watch it like a hawk as logs are generated, and resolve each one as it appears. In all likelihood, there will be a large number of duplicates, and possibly all of them will be duplicates.

i think swguy knows some additional info here??

if, in fact, it is your ZC log folder (which is not exactly clear to me), you can delete all of the ZC log files using the following command (assuming linux hosting) from within your ZC logs directory:

rm myDEBUG-*

you can understand a little bit more about inodes here:

http://www.inmotionhosting.com/suppo...g-linux-inodes

if you are getting a ton of ZC logs and you can not keep up with resolving those errors (as swguy suggests and which i completely agree), you can also set up a cron job to delete your log files on a daily/weekly/monthly (pick one) basis.

good luck.

[swguy]

The OP may not have ssh access to run rm. If your interface to the logs directory is through CPanel's File Manager, it will take forever to load a directory with a large number of files - it's not worth the headache since the problem is likely very easily reproducible.

Rather than a monthly automated deletion, I would recommend a monthly *manual check* to see if there are logs, and investigation of what caused them.

[carlwhat]

i love these philosophical discussions.... to a point...

if the OP does not have ssh access, what is the OP doing on a VPS?

if the OP were to have cpanel on his VPS, he would have had to install it himself. which if he is asking about inodes, i find highly unlikely...

personally i love having a VPS for a ZC site, but it does require sysAdmin functions, or the hiring of someone to do sysAdmin functions, IMO.

best.

[swguy]

You're right - I missed him saying his site was on a VPS.

[carlwhat]

You're right - I missed him saying his site was on a VPS.

hey, no worries. :)

i do agree that addressing log files and manually deleting them is a better idea than setting up a cronjob... i just wanted to present another way to address the inodes issue, as the site going down due to tons of debug logs is, IMO, rarely a good idea.

best.

[kevinmc3]

Thanks for the help and lively discussion.. I learned something.:)