17 days ago
I have a highly optimized, compiled Bun app running inside a Docker container on Railway. The app self-reports its own memory usage and it hovers around the 80-100MB margin.
However Railway's metrics report higher usage. I investigated this further and found out that Railway is also charging for the "page cache" from the container.
At one point in my test, the main app was self-reporting 82MB RSS but Railway was reporting 182MB (more than 2x).
Then I entered Railway console (thanks for that one!) and ran cat /sys/fs/cgroup/memory.stat, it reported the following values:
anon 44269568
file 135352320
kernel 2019328
kernel_stack 212992
pagetables 745472
sec_pagetables 0
percpu 6000
sock 0
vmalloc 24576
shmem 0
file_mapped 43896832
file_dirty 0
file_writeback 0
swapcached 0
anon_thp 0
file_thp 0
shmem_thp 0
inactive_anon 0
active_anon 44269568
inactive_file 37085184
active_file 98267136
unevictable 0
slab_reclaimable 617000
slab_unreclaimable 372184
slab 989184
workingset_refault_anon 0
workingset_refault_file 0
workingset_activate_anon 0
workingset_activate_file 0
workingset_restore_anon 0
workingset_restore_file 0
workingset_nodereclaim 0
pgdemote_kswapd 0
pgdemote_direct 0
pgdemote_khugepaged 0
pgpromote_success 0
pgscan 0
pgsteal 0
pgscan_kswapd 0
pgscan_direct 0
pgscan_khugepaged 0
pgsteal_kswapd 0
pgsteal_direct 0
pgsteal_khugepaged 0
pgfault 190346
pgmajfault 838
pgrefill 0
pgactivate 0
pgdeactivate 0
pglazyfree 0
pglazyfreed 0
swpin_zero 0
swpout_zero 0
thp_fault_alloc 0
thp_collapse_alloc 0
thp_swpout 0
thp_swpout_fallback 0
numa_pages_migrated 0
numa_pte_updates 0
numa_hint_faults 0which matches Railway's reporting.
I don't seem to have control of this page cache behavior inside a Dockerized app, so I can only optimize my code so much.
I heard in another topic that there's a "Runtime V3" coming that will let Dockerized apps have better control of this, if I understood correctly.
Until then, any advice?
7 Replies
Additional info:
The app uses multiple SQLite databases in a volume. Each database is configured with:
PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;
PRAGMA cache_size = -2000;
PRAGMA page_size = 4096;
PRAGMA mmap_size = 0;
PRAGMA journal_size_limit = 27103364;
PRAGMA busy_timeout = 5000;Goal was to minimize memory usage at the expense of disk usage, but it seems that disk usage causes page cache to increase, which increases memory usage...
The app also spawns subprocesses (that I call "jobs") via Bun.spawn. I have installed nocache in the container to start those subprocesses with nocache so that they don't increase page cache. I can't tell if it's working because Railway keeps reporting increased memory usage.
17 days ago
Runtime V3 is going to be MicroVMs instead of containers.
But as for the page cache counting as memory, that would be correct, and unfortunately, there's nothing I can offer you as a solution to that.
17 days ago
Most likely.
17 days ago
Railpack is not a runtime, it takes a code repo and packages it into a containerized image.
Railpack most certainly can, run complied executables - go, rust, bun, etc.