#wordpress nerds, i'm beating my head against the wall.

[kiki@thegayagenda.fans]

@tati@eldritch.cafe All I can think of is that the files were taking up too much of Wordpress’ allocated memory. Deleting the files immediately freed up the memory and fixed the issue.

[jibsaram@68k.social]

@tati@eldritch.cafe hi! The first thought that comes to mind is if those files are accessed (ie. downloaded) via a WordPress proxy path rather than a direct link, WordPress may be trying to load them entirely in memory as they pass through, which depending on your setup might be able to make everything rather memory constrained. Could that be a possible reason?

[tati@eldritch.cafe]

@jibsaram hi ! i don't think so ? i assume they gave a direct url, but it's definitely worth asking, and it would explain memory pressure. as far as setup, this thing feels underprovisioned. i didn't notice that until i put a periodic monitor on it, but it has less total memory than the size of any one of those files. the plugin i call the 'pig' is sometimes slow to load and i now think it's because of swapping. i didn't notice other heavy plugins, but now i definitely need to check for anything intercepting downloads. thank you for the ideas !

[ryse@mastodon.social]

@tati Maybe upload, monitor, and then delete those files a couple more times to see if you can consistently reproduce this memory issue to rule out a spurious correlation. That's what I would do just to make sure it was in fact the files.

If you have CLI access to the Ubuntu server, you can watch memory utilization in real-time with a tool called `htop`, check disk space utilization with `df -h`, and you might even check Apache/Nginx web server logs for errors around the time the site crashed.

[tati@eldritch.cafe]

@ryse thank you. it is a managed environment so du was more useful than df, that's how we saw that there were huge files out there. we reflexively burned them when we saw them as they were the most recent change, and it worked, but obviously i'm still trying to figure out why. i'm told the uploads went fine which is why nobody suspected a problem.

unfortunately our staging environment is provisioned differently from prod, and i wouldn't want to put prod in this spot again without having all-hands-on-deck outage prep. but since staging is smaller, we ought to see the problem more easily. that's something i'll try, thanks for helping me think straight. after something like this it's easy to go tasmanian devil and whack everything

[ryse@mastodon.social]

@tati Ah, gotcha. There are also WordPress plugins that can provide resource information and limitations right in WordPress (search: resource monitor). Maybe one of those would be helpful in staging as you do more testing. Good luck in your pursuit, and I hope you find the culprit. If all else fails, unleash the Tasmanian devil. ️

[iwein@mas.to]

@tati caching is my guess. I'm not the expert you asked for, so I have no idea which settings of which plugin to suspect

But until you get better responses I'd look at the caching settings.

The reason deleting fixes it may be that file not found is handled properly, and oom is not. By the plugin that's loading the file in memory... whichever that may be.
From the sound of it, disk is not the problem.

[tati@eldritch.cafe]

@iwein thank you ! indeed there's nothing obvious yet. there's just a lot of stuff that doesn't look quite big enough. even if we don't establish repeatable root cause, 'all this stuff is too tight' is definitely actionable

[iwein@mas.to]

@tati users should not use the web server for file sharing, is a reasonable rule too imho. I mean 🤯

Anyway, that's probably the most help I'm going to be, so I'll stop talking now ‍️

[tati@eldritch.cafe]

@iwein i did get that message across

[threadi@mastodon.social]

@tati That does sound very strange. Where exactly were the files located? In /wp-content/uploads/? Simply deleting them there could backfire, since WordPress creates database entries for all files; deleting the files doesn’t remove these entries - it just leaves empty shells with no content.

[threadi@mastodon.social]

@tati I would only see a memory issue if the files were being served via PHP. However, WordPress always links to files directly, without such a detour. Unless, of course, you’re using a plugin that handles this, e.g. a download counter. I’m therefore strongly suspecting that either a plugin you’re using or hosting limits are to blame. WordPress itself can handle files of any size (I know this because I’ve tested exactly these scenarios many times w/ my plugin External Files in Media Library).