* Craig James:
> So it never makes sense to enable overcommitted memory when
> Postgres, or any server, is running.
There are some run-time environments which allocate huge chunks of
memory on startup, without marking them as not yet in use. SBCL is in
this category, and also the Hotspot VM (at
Florian Weimer wrote:
* Craig James:
So it never makes sense to enable overcommitted memory when
Postgres, or any server, is running.
There are some run-time environments which allocate huge chunks of
memory on startup, without marking them as not yet in use. SBCL is in
this category, and als
* Craig James:
>> There are some run-time environments which allocate huge chunks of
>> memory on startup, without marking them as not yet in use. SBCL is in
>> this category, and also the Hotspot VM (at least some extent).
>
> I stand by my assertion: It never makes sense. Do these
> applicatio
Florian Weimer wrote:
* Craig James:
There are some run-time environments which allocate huge chunks of
memory on startup, without marking them as not yet in use. SBCL is in
this category, and also the Hotspot VM (at least some extent).
I stand by my assertion: It never makes sense. Do these
On Thu, 11 Sep 2008, Scott Carey wrote:
Preliminary summary:
readahead | 8 conc read rate | 1 conc read rate
49152 | 311 | 314
16384 | 312 | 312
12288 | 304 | 309
8192 | 292 |
4096 | 264 |
2048 | 211 |
1024 | 162 | 302
512 | 108 |
256 | 81 | 300
8
Good question. I'm in the process of completing more exhaustive tests with
the various disk i/o schedulers.
Basic findings so far: it depends on what type of concurrency is going on.
Deadline has the best performance over a range of readahead values compared
to cfq or anticipatory with concurren
