I'm not completely sure when this started, I suppose it's from when we enabled jemalloc(?), the "other" memory reporter is usually pretty large, on my system it's more than 50MB, larger than any other database page cache. Do we have any idea what does it take into account, is it just memory fragmentation? Was this memory previously accounted in heap-unclassified?
It's only about 4mb for me. I wonder if it slowly grows.
Created attachment 572466 [details] about:memory log in my case it goes up pretty fast to about 50MB, that's about the same size as places.sqlite cache, thus I have some doubt whether we may be double accounting memory...
For me, it is not the same size as my places.sqlite cache. At least not yet. (Also, your sqlite cache is 50mb?!)
yes, the cache adapts to the system specs, it's as large as it is designed to be (well, actually it's a bit larger than it is expected to be, that on my system is <45MB, bug 658303 should fix that though). Btw, we should figure out what's taking that memory, since looks really strange, I'd expect the caches to take up most of the needed memory here.
There is another interesting fact, my heap-unclassified is about 13% while before it was usually around 29%.
We're using SQLite's own memory reporters, I don't know what "other" includes, it's computed as SQLite's total memory usage minus all the per-connection stuff. As for the jemalloc thing, that improved our coverage of SQLite's memory usage from something like 80% to 100%. At least, they're the numbers I saw, but my profile sounds smaller than yours. Here's output from my current session: ├───14,331,208 B (05.15%) -- storage │ └──14,331,208 B (05.15%) -- sqlite │ ├───8,948,952 B (03.21%) -- places.sqlite │ │ ├──8,555,024 B (03.07%) -- cache-used  │ │ ├────328,376 B (00.12%) -- stmt-used  │ │ └─────65,552 B (00.02%) -- schema-used  │ ├───2,236,920 B (00.80%) -- other Bug 676189 comment 10 and bug 676189 comment 15 have some details about the numbers I saw. You're using a build that uses jemalloc, I assume? One useful thing might be if you can add some debugging printfs to sqliteMemMalloc and sqliteMemRealloc in mozStorageService.cpp, see if anything leaps out at you, e.g. many allocations of a particular size.
A "difference" on my profile is that my page size is 4096, not 32768. But aiui this shouldn't really matter. I see these numbers in today's nightly, on Win7x64 (classic 32 bit build though), btw and the "other" value is exactly the size I see missing from heap-unclassified, it was usually around 110MB, today it's around 60 MB and I have this sqlite "other" of 50MB, so in my case it was a large part of the unclassified stuff. I'll try to do some checks on the allocations, as you suggest. Any testing should be done on today's or yesterday's nightlies, that should be the most interesting ones.
Created attachment 572794 [details] SqliteMemRoundup log this is a list of requests to SQLiteMemRoundup, each row is a request, the former is the required size, the latter is the returned roundup. I should check which of these cause the largest slop, but looks like I have a lot of unefficient roundings 560,1024 1612,2048 32904,36864 4232,8192
So, after some magic calc sheet, I figured out the greatest offenders (bytes): Request | count | total | round | slop 4232 | 2445 | 10347240 | 20029440 | 9682200 32904 | 516 | 16978464 | 19021824 | 2043360 560 | 593 | 332080 | 607232 | 275152 1612 | 586 | 944632 | 1200128 | 255496 The first one is likely due to my page size, that is 4096, that becomes 4232 with the added header, and is then rounded to 8192. So I'd need about 10MB, but with the slop it's 20MB.
Note that we would like to convert these page sizes to 32768, but due to WAL we cannot fix the page_size through a vacuum, and we can't go out of WAL because we have prepared statements. We also have 1024 page_size databases in the wild, that are likely being rounded to 2048. We could do a one-time conversion on upgrade, but would take some time and users may think the browser froze on startup, killing the process in the middle of the vacuum. Bug 634374 covers the page size conversion problem, the idea was to add this task on upgrade, so at least there was a progress bar, but since the plan is to make updates silent and applied in background, that's not feasible. We need a system service that can do maintenance when the browser is closed, bug 481815 is implementing an upgrade service for Windows, but may be problematic to add SQLite support to it.
(In reply to Marco Bonardo [:mak] from comment #9) > So, after some magic calc sheet, I figured out the greatest offenders > (bytes): > > Request | count | total | round | slop > 4232 | 2445 | 10347240 | 20029440 | 9682200 > 32904 | 516 | 16978464 | 19021824 | 2043360 > 560 | 593 | 332080 | 607232 | 275152 > 1612 | 586 | 944632 | 1200128 | 255496 > > The first one is likely due to my page size, that is 4096, that becomes 4232 > with the added header, and is then rounded to 8192. So I'd need about 10MB, > but with the slop it's 20MB. Oh, that's absolutely the problem. With a 32KB page size it gets rounded up to 36KB. So changing to 4KB pages is a no-go without some other change to avoid the slop.
(In reply to Nicholas Nethercote [:njn] from comment #11) > Oh, that's absolutely the problem. With a 32KB page size it gets rounded up > to 36KB. So changing to 4KB pages is a no-go without some other change to > avoid the slop. I don't get your last phrase, we don't want to change to 4KB pages, we would like to STOP having 4KB pages and convert all DBs to 32KB pages... Btw the main issue is that changing the page_size is really hard while the browser is running.
Marco clarified for me on IRC. I thought he had a patch that reduced the 32KB page size down to 4KB, but that's not right. Turns out lots of existing users have 1KB or 4KB pages (because that's what we used to use). Anyway, this is covered by bug 699708.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 699708
You need to log in before you can comment on or make changes to this bug.