For reference, a PostgreSQL 8.0.8 with 2 persistent connections, one on a tiny database (only tens of rows per table) and one on a small database (hundreds of rows per table) looks like this on my Gentoo with a 2.6 kernel.
Code:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
postgres 3957 0.0 0.2 7220 196 ? S Aug31 0:03 /usr/bin/postmaster -D /var/lib/postgresql/data
postgres 4027 0.0 0.7 7220 696 ? S Aug31 0:15 postgres: writer process
postgres 4028 0.0 0.0 6936 64 ? S Aug31 0:02 postgres: stats buffer process
postgres 4029 0.0 0.3 6068 308 ? S Aug31 0:02 postgres: stats collector process
postgres 4125 0.0 2.7 7984 2584 ? S Aug31 0:12 postgres: sqlgrey sqlgrey 127.0.0.1(3599) idle
postgres 4385 0.0 1.5 7900 1476 ? S Aug31 0:00 postgres: vmail vmail 127.0.0.1(3601) idle
I suspect the total RSS is even smaller than the sum of its parts (postgres forks processes which then share the same memory pages).
This is a grand total of 5,3 - 5,4 M in resident memory (RSS). The database is accessed fairly often (several queries per email and several emails per minute).
The box is currently under a good amount of memory pressure (GCC 4.1.1 and Glibc 2.4 are now available -> I'm upgrading the whole box which implies a long standing background recompilation of each and every package) but PostgreSQL remains responsive.
I've tuned PostgreSQL for low memory usage by :
- lowering max_connections to 16,
- lowering shared_bufers to 64.
It may not be useful to you if you can't switch to PostgreSQL but :
- this means you may be able to tune MySQL to use less memory (see MySQL doc) like I did with PostgreSQL (it used to allocate 50% more memory at startup),
- you definitely don't need 14M for small databases.
Note that if you can avoid persistent connections, the total is squeezed to 1332 kB. You could even disable stats and get below 1M
