• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Resolved Caching is defined to 64MB, but it gets HUGE - many many gigabytes!!!

jmar83

Regular Pleskian
Hi there

1.)

ubsqPCm.jpg
VS.

2.)

[Image showing huge usage of Nginx caching directories, removed Feb 13th, 2023 for privacy reasons.]


TO BE HONEST:

WTF is that s**t? It f***ed up my server completely!!!!
 
Last edited by a moderator:
Questions:

1.)
How to solve / work around that f****ng nasty bug??

2.) How to empty / flush that caching files safely??
 
And the most disturbing thing on all is: That ~18GB file, from that NGINX will create LOCAL cache is even not on the local server / filesystem - it's on a COMPLETELY (!!!!) different IP in that case. (Plesk is just a reverse proxy - mod_proxy)

So WT... ?!?!??!?
 
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.
 
@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 #@§|¬§()/(ç¬... ;-)
 
@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...?


Xw4UQxi.png
 
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.
 
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...
 
The disk space occupation is not by a single cached file, but by many transactions that failed on the disk for some unknown reason.
 
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.
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...
 
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
"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.
 
switch "Statische Dateien direkt durch nginx bedienen" off, too, unless the static files are on a filesystem nginx knows to access.
 
Back
Top