Here is an update on postgres backend buffer performance (and problems).
I ran the regression tests with several sizes for the "-B" option for
postmaster. The best performance was for the run with the largest value
of -B. However, smaller values of -B seem to give results indicating a
large memory leak or garbage collection problem in the backend.
(results are for "time make runtest" under tcsh)
TEST1:
gemini$ /opt/postgres/current/bin/postmaster -B 128
...
ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out
1.550u 4.580s 5:56.25 1.7% 0+0k 0+0io 16984pf+0w
TEST2:
gemini$ /opt/postgres/current/bin/postmaster
ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out
...
1.250u 4.870s 6:45.65 1.5% 0+0k 0+0io 16863pf+0w
TEST3:
gemini$ /opt/postgres/current/bin/postmaster -B 16
...
ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out
1.580u 4.690s 13:29.13 0.7% 0+0k 0+0io 16843pf+0w
In all cases, if I repeat the regression test without restarting
postmaster, the elapsed time becomes significantly higher. For runs with
"-B 16", a second run of the regression test starts failing midway
through with messages indicating that buffer space is exhausted.
I am running on a RedHat Linux box with i686 processor(s).
Vadim (and others?), can you see this feature in your regression runs? I
am still sitting on Robert Withrow's Purify runs on the regression
tests. Would those be helpful? Since the regression tests have changed
so much since v6.0, and since many features tested in the new regression
tests are not available in v6.0, I don't know if it would be useful to
try running the new regression tests with the old release. I haven't
tried distilling the problem down to a single test, because I don't
really know what to look for or what is causing the symptoms.
- Tom
------------------------------
