Okay, but can you tell us what’s the reason for that new behavior? It’s working for more than one year with that setup. What makes Discourse different now than it has been in the past?
thanks for the recommendation. yea slightly strange i’ve usually gotten away with default 2GB swap file on a $5 Digital ocean droplet. will keep an eye out on if this becomes more common with latest updates or something.
anyways i went ahead and added a lot more swap (4 G) in a separate file
but the upgrade still failed. maybe more RAM is non-negotiable. just unexpected because the instance has 1 topic and 1 user at the moment. also curious if i need to do anything to make sure discourse knows to use the swap or if it is just accessible by default?
free -m output…
total used free shared buff/cache available Mem: 981 138 576 0 266 703 Swap: 6143 109 6034
Yep, I’m on a Digital Ocean Droplet with 1 vCPU and 1GB vRAM as well
I have increased the Swap memory onto 3GB. It’s still not working with same error.
I’m able to rebuild my test instance with only 2.5GiB of RAM+swap. It’s possible that your instance is requiring more than that, however.
Do you have any plugins installed? I suspect that one of them is causing massive memory use during compilation.
Can you rebuild without plugins and see if that fixes the problem?
Thanks for chiming in-
Out of curiosity what is the break down of RAM vs swap? and are you only counting what is “free” space on both of those or the total swap file size + total RAM of instance?
Oh right of course - i had forget to mention i was hoping to install the Discourse OpenID Connect Authentication plugin
Currently also have the Data Explorer plugin already installed.
- Tried again with only Data Explorer + Docker Manager and no luck, same stacktrace as shared before.
- Tried again with no plugins (just Docker Manager) and the rebuild still didn’t work.
will keep looking around since outside of trying to add the ConnectID plugin i haven’t changed anything since original install
I am having a problem that might be related over at Trouble with `tests/test_helper`? - #2 by Falco.
I tried to rebuild app without any plugins. No change. Same error.
I don’t understand this, but it looks like a bug. I’m trying to do a bootstrap on this site. No non-standard plugins. I just moved assets from one bucket to another and it’s all working. I was doing one more rebuild to add
DISCOURSE_S3_UPLOAD_BUCKET to the ENV so that it won’t show up in the UX. When this failed the first time, I commented out that line and tried again with the same config that worked 3 days ago.
I wondered if there was some problem with the CDN url, but all the lines above included it and worked fine.
Does this mean there’s faulty CSS in their theme? If so, ouch. There’s only some CSS in their master theme. Also these components:
Is this a minimum size droplet? Looks like that file is kinda hard for terser to compress as it causes a lot of memory pressure.
Oh. It is surprisingly small. It’s a site that I think you guys set up some years ago (when you’d still run a site not on your infrastructure).
root@community:/var/discourse# free -h total used free shared buff/cache available Mem: 1.9G 1.2G 101M 259M 655M 354M Swap: 2.0G 1.2G 773M
Ah. OK. It’ s 2GB DO droplet, and I have access to their control panel. I’ll tell them that we need to upgrade to 4GB and move them to an AMD.
EDIT: But if this is just to compress that one file, shouldn’t a 2GB droplet be enough?
This test-helper file is hard on the compression.
UglifyJS uses 1.5GB RAM to compress it.
Terser uses a little over 1GB. Takes 40s. For comparison the same server takes 8s on Ember+jQuery
@eviltrout should we even have this file in production?
Ohh looks like it comes from this change from @Osama
-rw-r--r-- 1 discourse discourse 14M Apr 26 19:13 _test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js -rw-r--r-- 1 discourse discourse 6.6M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js -rw-r--r-- 1 discourse discourse 1.1M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js.br -rw-r--r-- 1 discourse discourse 1.5M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js.gz -rw-r--r-- 1 discourse discourse 5.7M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js.map
Just to add another data point - still experiencing the rebuild failures after removing the two theme components. So just using the default Light theme.
also where is this output from - looking to verify/debug a bit on my end as well. is this like a verbose option on the
./launcher rebuild app?
Fixing this properly is going to take a little while, so I’m going to revert that change for now.
It may be a good idea to put it behind a feature flag afterwards so we can iterate on it internally.
Ok it’s been reverted and the commit is in tests-passed now:
Thanks for letting us know and sorry for the inconvenience.
I’d be interested to hear if this revert has also solved the OP’s problem. The OP (@devnull ) reported seeing
which wasn’t reported by @pfaffman
Also I’d like to comment on this:
Adding RAM can sometimes improve performance, but for actually running out of memory, what counts is RAM+swap. If adding swap doesn’t help with an out of memory condition, then adding RAM won’t either.
As @weallwegot reports the failure persists even after adding 4G of swap, something is (or was) very hungry indeed.
It’s the same error. Reading the backtrace shows a reference to OOM on the fourth line.
All of that is true. He has < 1GB of ram, which isn’t much. So even if he didn’t have this problem, I’d still recommend that he add more RAM. For that matter, I mostly recommend that anyone with <2GB of ram increase their RAM.
The problem is resolved for me. Rebuild App works. Thank you very much for your effort!