Website Keeps Running Out of Memory

[Sparetoolparts]

Hi Guys



I've got a M2 2.4.5 site, that over the last few days has been continually crashing due to disk space running out.



My developers have been removing old files and backups etc, and at one stage last week had brought the disk space down to 63% used, but then 2 x days ago the site went down with no space left and again we removed 40G of redundant old files etc and the site came back for a while but it is now down again.



We are getting to the point where there is very little left to remove if anything.



When my host looks at the folder breakdown they can see the biggest overall folder is



/var/www/vhosts/sitename/htdocs/pub/media/catalog/product/image



I have spotted something strange for some unknown reason to me folders appearing in this directory from the 22nd Dec 2023, the previously created folders in the directory was: 13-10-2022

So something is creating these folders and are putting images into them.

I've not been adding new products or updating images. The only thing I have been doing is bulk updating a text attribute called sparelink.

I have been doing this via the default Magento Import functionality. I have been updating 15,000 products at a time ( I would estimate I have updated over 200,000 products in Dec)

Some times the importing is timing out, so I let it go for a while, find the products that were last updated, create a new .csv file and start importing the products that weren't done. At this stage the import then completes successfully.

I can't see me updating a text attribute with a new value can be causing any problems? what else could be creating these folders with images in them?

Has anyone come across this issue before? Could the default importer being trying to update images of its own accord and be creating duplicates or something?

Where would my host need to look to see if a importing process is still running somewhere?

 

[Sparetoolparts]

Just a bit of extra information



The folders that are being created are named with random letters



the actual image itself is name the same as product title an example is here:



/var/www/vhosts/sparetoolparts.co.uk/htdocs/pub/media/catalog/product/image/24306488a9b



The image is called:



milwaukee-ag-8-carbon-brush-4931453529-spare-part-serial-no-4000452812.jpg



When I look my .csv file I can see that the original image used for this product was called:



4926452804.jpg



When I look here:



/var/www/vhosts/sitename/htdocs/pub/media/catalog/product/4/9



I can see the original image in the correct directory.



So I've no clue where or why this image is being created.

 

[Nick@Daydot]

Just a random thought - can you see from server logs if the images in question are being called, and if so where from. So if for example someone has set up a copycat site and is calling the images from your server?

Have you checked the access logs to your server and changed the password?

 

[DontAsk]

Image cache files? Are they the same size as the originals?

 

[Sparetoolparts]

@DontAsk

I'm not sure ref Cached images, but shouldn't they be appearing in cached folder and not the image folder?

When I look in the cached folder it is still generating content:

/var/www/vhosts/sparetoolparts.co.uk/htdocs/pub/media/catalog/product/cache/c9e5b09b03c83272c4f6a92b4a520676/image/24142687b30

interestingly it is creating images with the full product title as well. just like the image folder.

So it may well be a cache issue.

Anything thoughts on moving forward though?

Due you think it would be safe to delete these folders and images from the product/image folder?

 

[Sparetoolparts]

just a little update, I eventually Flushed Magento Cache and the site hasn't gone done since, I suspect it will again though when the Cache uses all the space again. I'll just need to keep flushing it until we can figure out why Cache is taking so much space

 

[NickZ]

I eventually Flushed Magento Cache and the site hasn't gone done since,

You should look for getting more memory, up your plans, change server, whatever it takes.

 

[Sparetoolparts]

no issues like this before I done an upgrade to 2.4.5 and I've not added new products since then, so memory usage should not be spiking like it is, hopefully I'll not need more space and problem is elsewhere. I'll need to see what my developers say

Thanks for the input

 

[NickZ]

I done an upgrade to 2.4.5

When looking at tech development, an upgrade comes with more "needs" than before.
Imagine a win 3.1 running on a i7 with 16 GB RAM.

 

[fisicx]

When looking at tech development, an upgrade comes with more "needs" than before.
Imagine a win 3.1 running on a i7 with 16 GB RAM.

That makes no sense. Why would an issue with the cache need a server upgrade? This seems to be a systems setting or maybe even a bug with Magento.

@Sparetoolparts - have you asked the question on the Magento support forums?

 

[Sparetoolparts]

I've asked the question yea ref the forum. Will await feedback on that

the upgrade was done months ago

In and around that time it started writing to that image directory we removed the staging site in an attempt to help resolve a Redis issue.

Everything seemed find until the crash

 

[NickZ]

That makes no sense.

You have forgotten to add : for you.

When the content of a cache already creates a system freeze resources are not that abundant.

 

[fisicx]

You have forgotten to add : for you.

When the content of a cache already creates a system freeze resources are not that abundant.

The issue is how the cache is being created not the amount of memory. Fix the caching problem and the site won’t crash.

Running out of memory is the symptom not the cause.

 

[antropy]

It looks like cached image folders are growing too big.

You should ask your developers to see if there is a way to prevent such a large cache being needed and if not, you should increase the disk space on your server.

Paul.

 

[Sparetoolparts]

were exactly should the Cached imaged being saved to?

I would assume it would be the cached folder and not the image folder where at present is where cache images are going

 

[antropy]

were exactly should the Cached imaged being saved to?

It doesn't matter where they're saved to, that won't affect their size.

There are different ways to cache things and there may be a way your developers can reduce the amount of space needed this way. You could also make sure old product images are removed.

These are things for your developers to help you with, you shouldn't really need to be asking these questions here, it's quite simple work for a decent developer.

Paul.

 

[Paul Kelly ICHYB]

There are different ways to cache things and there may be a way your developers can reduce the amount of space needed this way.

CDN?

 

[antropy]

CDN?

Not really an alternative here as some server-side caching will be needed to resize and optimise the images.

Paul.

 

[dx3webs]

HI there

/var/www/vhosts/sitename/htdocs/pub/media/catalog/product/image
is not a standard magento storage location. What does the contents of this folder look like?

I suspect some 3rd party module is inserting the images into this folder.

In fact the only google result for

"pub/media/catalog/product/image" is this conversation.

 

[HostXNow]

Also, check cronjobs to make sure something isn't running if it shouldn't be

 

[goivvy]

Are you using Klevu search extension?

catalog/product/image folder is used by Klevu to store product thumbnails.

 

[Sparetoolparts]

Hi Guys

Thanks for replying

The site has been up and down again over the last few days with the same issue, I've been removing whatever old backups etc I have on the server but I'm scraping the barrel now for extra things to remove.

@dx3webs

pub/media/catalog/product/image

This is still filling up with new folders and images on a hourly basis

I'm thinking I should remove all these folders/images dated from the 22nd until now. But my concern is what affect might this have on the front end? And how can I test that it won't make things worse?

My developers are unavailable until Tuesday so i'm on my own here :-(

 

[Sparetoolparts]

@HostXNow

Not sure I can do this myself or know what to look at :-(

@goivvy no I'm not using anything from Klevu

 

[dx3webs]

You can always rename
pub/media/catalog/product/image
to
pub/media/catalog/product/image.off
and see if there are any negative consequences.. if there are.. put it back. if not then it should be safe to remove the folder (verifying the off sites backup 1st)

 

[goivvy]

What if you just make pub/media/catalog/product/image folder read-only and see if anything comes up in var/log/system.log or var/log/exception.log. Check out new exception reports in var/report and see if anything is in there. You could use that trick to see what module writes all those image files.

 

[Sparetoolparts]

@goivvy I did try that, but it only ended up creating the folder again itself! :-(

However the good news is, my developers were able to find a random Cron Job which was coping the images, this has now been removed and the folder emptied, happily at present the site is only using 69% of of the available space on the server

Hopefully it stays this way. Thanks to everyone for their feedback

 

[antropy]

my developers were able to find a random Cron Job which was coping the images

Ok, and did they say what it was doing? It was probably there for a reason. From what you've said I'm not getting the impression they really know what they're doing.

Paul.

 

[Sparetoolparts]

Not Yet I've asked the question though

 

[antropy]

Not Yet I've asked the question though

Do they have much Magento experience?

Paul.

 

[fisicx]

However the good news is, my developers were able to find a random Cron Job which was coping the images…

How did it get there in the first place. Cron jobs have to be created so who made it?

 

[goivvy]

@goivvy I did try that, but it only ended up creating the folder again itself! :-(

I wonder how a read-only folder got re-created.

 

[Paul Kelly ICHYB]

Some strange hack/worm?

 

[Sparetoolparts]

Details Provided by Developer

Hi Guys

The images continue to be created and are crashing the site every few days, I now have a cron job clearing the directory each day but this in itself is causing issues due to the size of the directory.

I've a crazy idea of simply deleting the Magefan_blog directory and hope this resolves the issue as at present my developers are unable to figure this out.

Any thoughts from you guys?

FYI

The Magefan Blog has been disabled and by the looks of it even removed on the backend, but obviously the underlying code isnt!

 

[antropy]

I've a crazy idea of simply deleting the Magefan_blog directory and hope this resolves the issue as at present my developers are unable to figure this out.

Any thoughts from you guys?

I suggest you find some developers who know what they're doing or switch platforms.

Deleting random things and hoping for the best is not the way to treat a live ecommerce site.

Paul.

 

[Sparetoolparts]

oh I know Paul

Just typing out of desperation here more than anything

Again switching platform will be looked at, but I need some stable run time to build a war chest before I do so

 

[antropy]

Again switching platform will be looked at, but I need some stable run time to build a war chest before I do so

But if you fix the problem then you won't switch ... until the next bug rears its head, at which point you won't have time to switch platforms.

Anyway the problem is probably that your source images are too big so the server simply doesn't have enough space to keep all the different cached version sizes.

Reduce the size/quantity of your source images, increase your server space, or remove the extension that is caching them.

You really need to have developers on hand who know what they're doing if you're running Magento, or indeed any platform.

Paul.

 

[fisicx]

@Sparetoolparts - your problem stems from using developers who don’t really know what they are doing and a whole bunch of plugins, extensions and customisations that are conflicting and breaking the site.

Don’t try to fix it. Change platforms.

And then get your listings sorted. You were unable to supply any of the items I wanted. So I got them from your competitors.

 

[ctrlbrk]

@Sparetoolparts I don't know much about Magento - I just second the 2 latest remarks - it's obvious this thread has been going on for a while and a problem such as this should have been sorted by people who know what they're doing.

Just ditch whoever isn't being capable of handling this and get someone who does.

 

[antropy]

@Sparetoolparts - your problem stems from using developers who don’t really know what they are doing and a whole bunch of plugins, extensions and customisations that are conflicting and breaking the site.

Don’t try to fix it. Change platforms.

And then get your listings sorted. You were unable to supply any of the items I wanted. So I got them from your competitors.

Yep totally agree:

1. Your developers really don't know what they're doing.
2. Even if you don't go with OpenCart, Magento is not a platform you can run on a shoestring budget and you should move for these reasons.

Paul.

 

[Sparetoolparts]

ok Guys

So Update on this

Old Developers are Gone / Given Up / Moved On /Bye Bye

My new developer has found and resolved the issue in a few hours!

So it turns out nothing was actually wrong, a plugin setting had been turned in Dec to rename images to more SEO friendly versions, what we didn't realize was that rather then renaming images, the plugin made copies of each image and renamed that instead.

This wouldn't be an issue for a smaller website but a site of my size it was a resource killer.

I thought I had ruled out the plugin as I had turned off the option I had turned on pre-Christmas. But the developer spotted then even though it was disabled it was still running.

Lesson Learned, Don't Turn things on unless you know exactly what they are doing.


Thanks to Everyone who contributed to this post.