mirror of
https://github.com/benbusby/whoogle-search.git
synced 2026-04-25 12:15:50 +03:00
[GH-ISSUE #28] [BUG] High RAM usage #19
Labels
No labels
Fixed (Pending PR Merge)
Stale
bug
enhancement
enhancement
good first issue
help wanted
keep-open
needs more info
pull-request
question
theme
unfortunate
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/whoogle-search#19
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @chpatton013 on GitHub (May 12, 2020).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/28
First off, I'm really excited about this project! I've been looking for something more approachable than searx for quite awhile, and was really happy to see you publish this. It seems like a great project, and I'm looking forward to using it. That said...
Describe the bug
Whoogle seems to use a lot of RAM, even before a single request has reached the application.
To Reproduce
Steps to reproduce the behavior:
docker run --name=whoogle-search --init --rm benbusby/whoogle-searchdocker stats --no-stream whoogle-searchMEM USAGE / LIMITcolumnExpected behavior
Essentially, less RAM usage.
Desktop (please complete the following information):
I'm testing this in a VM on my laptop, using Vagrant with a VirtualBox provider.
Additional context
I'm seeing 264MB used by whoogle in my local VM cluster. I tried to deploy this to a t3a.nano in EC2 (456MB RAM), but triggered OOM killer (the docker daemon uses a lot of RAM on its own, which leaves that machine with about 250MB of RAM free). Unfortunately, this is the RAM usage at-rest. I haven't even directed a request at this application yet, and it's already allocated over a quarter of a gigabyte.
For context, most PHP applications run with a default memory limit of 64MB, and many will operate just fine with a limit of 32MB (for example, bookstack, which I'm operating right now with 23MB of RAM usage). RAM is sparse in VMs (both locally and in the cloud), so anything you can do to lower the RAM requirements of the application will make this project more viable for a wider variety of users.
@benbusby commented on GitHub (May 12, 2020):
Yikes. I tracked it down, looks like the library I was using to make funny rhymes out of the User Agent was extremely inefficient with memory. Bypassing that knocked it down to about 30MB of RAM. All that memory for a stupid joke...tsk tsk. Thanks for pointing that out, will push a fix soon.
@benbusby commented on GitHub (May 12, 2020):
Fixed in
445019d204, will document in upcoming release in the next few days. Thanks again!@chpatton013 commented on GitHub (May 12, 2020):
Wow, that's pretty incredible. I wasn't expecting it to be too difficult to fix, but I didn't anticipate it all coming from one dependency. Thanks for the fast turn-around time! I'll keep my eye out for that next release.
I looked into
Phyme, and it looks like all that memory is used for the dictionary storage (and resulting lookup structures). Another good reminder that although Python is really convenient to work with, it has some serious costs on the hardware.