cache is huge in 2016.x EAPs
I have system/caches folder is 13G after update to 2016.x EAPs on my PC.
I working on large Zend Framework 2 project, which never has caches more than 1-2Gb before.
But funny thing, on 2 notebooks cache still small after updates.
Any known way to diagnose and fix this problem?
Please sign in to leave a comment.
Is it on OS X? Could you run File > Invalidate Caches/Restart > Invalidate and Restart and check the caches after that?
Ubuntu 14.04 LTS. Tried it already, same result - 13Gb cache.
On notebooks (Ubuntu 16.04 LTS, OSX 9) - less than 1Gb, same project, same settings and IDE versions.
Hello,
Please check what files are there?
Clearing caches should have been empty the folder so if the size is the same then files there are either bogus or not related.
It is safe to delete the caches so you can just empty the 'caches' directory manually and check if this will occur again.
system/caches/content.dat.storageData is a beast, 13Gb while whole system/caches folder is 14Gb
I tried this already - wiped whole system folder - no results, huge cache recreated when I load this ZF2 project (any other PHP/ZF2 projects creates small caches).
Thanks!
That's weird but it may depend on what you have in your system PHP SDK - it is being indexed there as well.
Could it be that you have lots of enabled PEAR extensions, for example?
Thanks God or JetBrains, problem solved with some recent EAP! :)
I work in 2016.2.1 EAP 162.1628 now. 200 Mb cache instead of 15 Gb after whole system folder recreation.
Not really. With 2018.2 I still have 20 GB of cache (maybe more, if I had more free space). But I think I've found the cause: in some folders, I have about 300.000 image files (*.jpg) in the same folder. I don't know why PhpSform tries to read these files.
>I don't know why PhpSform tries to read these files.
For example -- for image size completion in HTML (<img> tags).
If you do not need that or it takes too much time reading those files etc -- better mark such folder as excluded.
Thank you. That's what I did when I found these files: marked the whole folder as excluded. I don't know how 300.000 filenames can take 20 GB (and could be more, I didn't have free space when PhpStorm was indexing), maybe there is something to optimize?
Yes, this is unlikely to be caused by file names.
Does the cache grow again if you delete it?
I don't know. My normal cache (without openning this project) is about 3 GB. By opening this project it was growing over 20 GB and I ran out of disk space. I deleted the cache folder but it was created again and was growing again (at about 10 MB/s, so I was again out of space in less than half an hour). The behavior was consistent, and it was not the first time. I had had this problem, I think with this project too, a few months ago.
I tried to enable Power saving mode, but it did not seem help. Maybe once indexing starts, it won't stop until it finishes. I opened the indexing status, and saw it stuck on that folder, then I found the problem.
Is there a chance you could submit this project (or its part that reproduces the issue) within a bug report?
https://youtrack.jetbrains.com/newIssue?project=WI
I assume the archive will be heavy, so you can upload it here: http://uploads.services.jetbrains.com/
Sorry I can't share this project to a 3rd party. Maybe you can try to reproduce such a project: it's a Drupal 8 project using PhpStorm, in one folder there are 271372 files (all are *.jpg) with a total size of 20 GB. These files have relatively regular naming pattern XXXXXXXXNNNNNN.jpg.
What IDE version are you running? Please try to delete cache (see System directory), then install EAP build and check the issue there.
I always use the latest version of PhpStorm installed via snap (in Ubuntu). So it happened last week, and also a few months ago, with the latest version everytime but I don't know exactly which version. Delete the cache folder (~/.PhpStorm2018.2/system/caches right now) didn't help, as when I open that project, it grew again.
Right now I don't have that issue, as I excluded the folder, it solved the problem for me. I need a stable version to work with, so for the moment I won't install EAP builds. BTW have you tried to reproduce with what I described in the previous comment?
We unfortunately don't have 20GB of unique images at hand.
We've tried that with 20 GB of image set copies but it did not reproduce the issue.
Generally this issue has risen once: https://youtrack.jetbrains.com/issue/WI-10252 - there's a task to optimize image indexing: https://youtrack.jetbrains.com/issue/IDEA-82730.