Last call for 2.4.3 problems

Russ Allbery rra at stanford.edu
Fri Jan 27 20:08:15 UTC 2006


Ulrich Schmid <schmid at switch.ch> writes:

> from the ChangeLog of 2.4.2 (missing in 2.4.3 ChangeLog):
> 2004-06-02 20:11  hkehoe
>     * history/hisv6/hisv6.c: In hisv6_reopen(), if MMAP_NEEDS_MSYNC and
>       INND_DBZINCORE are set and nfsreader is false, override INCORE_NO
>       to INCORE_MMAP

> 2004-06-02 20:02  hkehoe
>     * lib/dbz.c: Put msync call in putcore for INCORE_MMAP Move
>       writethrough test from dbzsync to putcore because it only applies
>       to INCORE_MEM

> whereas I assume that my problem is due to the changes in dbzsync /
> putcore.  If I use in 2.4.3 dbzsync as of 2.4.1 I got the same history
> performance as with 2.4.1. Is the writethrough test correct in putcore?

Well, it's working for everyone else....  This is my timing from a box
running the 2.4.3 prerelease:

INND timer:
Code region                   Time    Pct    Invoked  Min(ms)  Avg(ms)  Max(ms)
article cancel        00:00:30.339   0.0%       2963    0.200   10.239  131.000
article cleanup       00:03:46.943   0.3%     765822    0.260    0.296    0.506
article logging       00:03:48.709   0.3%     767065    0.257    0.298    0.483
article parse         02:30:18.922  10.4%   24586049    0.265    0.367    0.638
article write         00:09:09.753   0.6%     152777    0.812    3.598    8.803
artlog/artcncl        00:00:00.779   0.0%       2320    0.000    0.336    3.636
artlog/artparse       00:00:01.335   0.0%       4152    0.000    0.322    2.189
data move             00:05:40.135   0.4%   28167766    0.007    0.012    0.024
hisgrep/artcncl       00:00:15.519   0.0%       2037    0.000    7.619   23.750
hishave/artcncl       00:00:00.277   0.0%       2963    0.000    0.093    0.689
history grep          00:00:00.000   0.0%          0    0.000    0.000    0.000
history lookup        00:03:30.670   0.2%    3224302    0.055    0.065    0.267
history sync          00:00:29.634   0.0%        290    0.000  102.186  274.000
history write         02:34:00.357  10.7%     767656    9.966   12.037   25.172
hiswrite/artcncl      00:00:09.341   0.0%        926    0.000   10.087  241.500
idle                  13:23:41.101  55.8%   20194447    1.592    2.388    4.849
nntp read             02:56:15.477  12.2%   25689788    0.326    0.412    0.550
overview write        00:00:00.000   0.0%          0    0.000    0.000    0.000
perl filter           00:48:59.092   3.4%     764238    2.626    3.846    6.378
python filter         00:00:00.000   0.0%          0    0.000    0.000    0.000
site send             00:13:34.637   0.9%     288804    2.037    2.821    3.480

TOTAL: 24:00:02.767   22:54:13.020  95.4%          -        -        -        -

According to your previous message, your system is taking over two
*seconds* for each call HISsync, which really makes no sense.  Could you
be tickling a bad disk block, perhaps?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list