/purge/* will cause 100% of disk io usage

[cdliaozhi]

I use Azure VM with nginx as the reverse proxy. And add a 64g Premium SSD as cache disk. When I use /purge/* to clear the cache, the disk IO exceeds 100%.

[denji]

Configuration file you have may be affected by other nginx settings like thread async i/o, cache lock.
What is the number of objects to be deleted (cache folder)? This module has no barrier or throttling.

[cdliaozhi]

My OS is FreeBSD 12.0. No async i/o. No matter I set proxy_cache_lock on or off, the same failure will occur.
Even if I purge a new site, just 28 pages.

[cdliaozhi]

I found that when I purge with wildcard, it will traverse all my cache files. My cache files is very huge, so it cause 100% of disk io usage. Denis Denisov <notifications@github.com> 于2020年9月23日周三 上午12:52写道：

…

Configuration file you have may be affected by other nginx settings like async i/o. What is the number of objects to be deleted (cache folder)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQ4GSITOPFU4HADPQPKSAZTSHDI6VANCNFSM4RVN4WBA> .

[midorinet]

I'm having the same issue here.. any workaround for big cache size like > 300GB ?

[cdliaozhi]

Just about 10GB. midorinet <notifications@github.com> 于2020年9月29日周二 上午11:08写道：

…

I'm having the same issue here.. any workaround for big cache size like > 300GB ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQ4GSIVTEZTEBVPTDQGCWW3SIFFSNANCNFSM4RVN4WBA> .

[ennorehling]

Earlier today, I explained why this happens, here:
FRiCKLE#55 (comment)
It's a fundamental problem with the way the plugin decides what is matched by a partial cache_key. There's apparently no easy way to find the cache_key for a given cache node, so instead it opens every file in the cache and reads the cache_key from that (it's stored as a string directly after the header). This is obviously going to hurt the disk. IMHO, this plugin is fundamentally flawed, and this isn't even the only problem with it.

[pei-jikui]

delete the file from disk in a worker process is REALLY NOT a good idea.