Facebook
Twitter
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
Resolved Caching is defined to 64MB, but it gets HUGE - many many gigabytes!!!
- Thread starter jmar83
- Start date
The Nginx cache directories descend from /var/cache/nginx and are named by the domain domains. To empty an Nginx cache, you can simply delete the corresponding cache directory from that tree.
In your screenshot you are referring to a temporary directory where Nginx downloads files that it shall cache, then moves these files into their real cache directories. Normally, /var/lib/nginx/nginx/proxy/* should be almost empty at all times. If it is not, maybe a website or your Nginx server has a wrong configuration, e.g. the "proxy_cache_path" set to a wrong value or maybe even to /var/lib/proxy instead of their final destination. If you have installed Nginx through Plesk and let Plesk configure it for your, it should all be configured correctly. If you have added your own configurations or not had Nginx installed through Plesk or modified it later, that could lead to the issue described above.
You could try to run
# grep -R proxy_cache_path /etc/nginx/*.* | grep /var/lib/proxy
to identify entries for that the proxy_cache_path line includes a reference to /var/lib/proxy. As far as I know, it is safe to remove the proxy/* directories as they should be recreated when Nginx needs them.
In your screenshot you are referring to a temporary directory where Nginx downloads files that it shall cache, then moves these files into their real cache directories. Normally, /var/lib/nginx/nginx/proxy/* should be almost empty at all times. If it is not, maybe a website or your Nginx server has a wrong configuration, e.g. the "proxy_cache_path" set to a wrong value or maybe even to /var/lib/proxy instead of their final destination. If you have installed Nginx through Plesk and let Plesk configure it for your, it should all be configured correctly. If you have added your own configurations or not had Nginx installed through Plesk or modified it later, that could lead to the issue described above.
You could try to run
# grep -R proxy_cache_path /etc/nginx/*.* | grep /var/lib/proxy
to identify entries for that the proxy_cache_path line includes a reference to /var/lib/proxy. As far as I know, it is safe to remove the proxy/* directories as they should be recreated when Nginx needs them.
Note, next time you will be banned for such inappropriate expressions.
@Peter Debik: Thank you very very much for your feedback. Will look ASAP on it!! 
@IgorG: I'm sorry, but i really can't see any inappropriateness - my expressions are adequate i.m.o...
that i just #@§|¬§()/(ç¬... ;-)
@IgorG: I'm sorry, but i really can't see any inappropriateness - my expressions are adequate i.m.o...
that i just #@§|¬§()/(ç¬... ;-)
@Peter Debik:
"If you have installed Nginx through Plesk and let Plesk configure it for your, it should all be configured correctly. If you have added your own configurations or not had Nginx installed through Plesk or modified it later, that could lead to the issue described above."
I never changed something in the "background" - so it's "buggy by default", so to say...?
The weird thing is that these files are even NOT locally saved - my plesk vserver does act as a reverse proxy only for some sites... and files from the remote (target) domain that sites will be cached? I don't think that's technically necessary and should be turned of by default? Maybe not a bug, but a wrong setting...?
"If you have installed Nginx through Plesk and let Plesk configure it for your, it should all be configured correctly. If you have added your own configurations or not had Nginx installed through Plesk or modified it later, that could lead to the issue described above."
I never changed something in the "background" - so it's "buggy by default", so to say...?
The weird thing is that these files are even NOT locally saved - my plesk vserver does act as a reverse proxy only for some sites... and files from the remote (target) domain that sites will be cached? I don't think that's technically necessary and should be turned of by default? Maybe not a bug, but a wrong setting...?
I think that this is the wrong place to look at. You are mixing up reverse proxy and Nginx caching. These are two different things. Your issue is related to Nginx caching, but not on Nginx acting as a reverse proxy.
You can try to deactivate Nginx caching and see if the problem persists. If you deactivate caching, most likely the issue cannot occur again. Caching is nice, but it is not really needed for website operations. You'll still have your Nginx as a reverse proxy, and it will still deliver static files, hence speed up your website. It will however simply read the files from disk when they are requested and not store them in its cache.
Plesk's Nginx configuration is not buggy and proven to work on millions of servers.
You can try to deactivate Nginx caching and see if the problem persists. If you deactivate caching, most likely the issue cannot occur again. Caching is nice, but it is not really needed for website operations. You'll still have your Nginx as a reverse proxy, and it will still deliver static files, hence speed up your website. It will however simply read the files from disk when they are requested and not store them in its cache.
Plesk's Nginx configuration is not buggy and proven to work on millions of servers.
Thank you very much for your feedback. Before, the nginx caching was activated [Screenshot on initial post on this thread], but it was ONLY (?) 64 MB - so limited.
If there is a file that exceeds that 64 Mb size, that file will not be bypassed by caching mecahnism - i.m.o. the 64mb rule will be ignored and all files they are bigger than that size will be cached to - instead they will be ignored / disabled from caching...?
Anyway - i will look what happens in future...
If there is a file that exceeds that 64 Mb size, that file will not be bypassed by caching mecahnism - i.m.o. the 64mb rule will be ignored and all files they are bigger than that size will be cached to - instead they will be ignored / disabled from caching...?
Anyway - i will look what happens in future...
If nginx is a reverse proxy for another server, I think it won't deliver static files
But it seems it does - at least with my config... since i gave that ~18GB file download link (due to a bug report) to a company for investigation, Plesk started
a.) With the Web GUI quota messagees
AND
b.) To fill that directory /var/lib/nginx/nginx/proxy/
Yes, the activation of 64MB caching was my fault - mea culpa... but i was never thinking about that behavior...? Maybe a thing (bug report) for the plesk developer team?
(Firstly, i was thinking it's the mail log and/or my .img file for iSCSI target... but it was not... then i figured it out with the command ´du -h -s /var/lib/nginx/proxy/* 2> >(grep -v '^du: cannot \(access\|read\)' >&2) | grep G´ ... -> Nach Löschung grosser Mail-Log-Dateien unter /var/log/... noch immer 99% vom Speicherplatz besetzt? [Gelöst] - debianforum.de , for those who understand the german language ... )
The reverse proxy (mod_proxy) configuration is posted as a screenshot in this thread...
a.) With the Web GUI quota messagees
AND
b.) To fill that directory /var/lib/nginx/nginx/proxy/
Yes, the activation of 64MB caching was my fault - mea culpa... but i was never thinking about that behavior...? Maybe a thing (bug report) for the plesk developer team?
(Firstly, i was thinking it's the mail log and/or my .img file for iSCSI target... but it was not... then i figured it out with the command ´du -h -s /var/lib/nginx/proxy/* 2> >(grep -v '^du: cannot \(access\|read\)' >&2) | grep G´ ... -> Nach Löschung grosser Mail-Log-Dateien unter /var/log/... noch immer 99% vom Speicherplatz besetzt? [Gelöst] - debianforum.de , for those who understand the german language ... )
The reverse proxy (mod_proxy) configuration is posted as a screenshot in this thread...
"deliver static files" means it delivers them on its own, reading from the vhost's path in the filesystem, not getting them by asking upstream. If the website really is on another server, that won't work for reasons that should be obvious.
Why it caches a 18G file is another thing. Problem is, if nginx starts to load that file from upstream, and then notices it is too big for the cache, there is no easy way to stop the download without breaking the transaction, which could be even worse.
That it does not clean up said file afterwards could be a nginx bug.
Similar threads
