Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #260943 > unrolled thread

Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...]

Started by<kjohnson@eclypse.org>
First post2023-08-15 00:20 +0200
Last post2023-08-15 04:40 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.debian.user


Contents

  Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...] <kjohnson@eclypse.org> - 2023-08-15 00:20 +0200
    Re: Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...] Stefan Monnier <monnier@iro.umontreal.ca> - 2023-08-15 04:10 +0200
    Re: Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...] Max Nikulin <manikulin@gmail.com> - 2023-08-15 04:40 +0200

#260943 — Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...]

From<kjohnson@eclypse.org>
Date2023-08-15 00:20 +0200
SubjectDisk writes much slower in Bookworm i386 [Was: svnadmin dump ...]
Message-ID<H2O4N-1U4g-7@gated-at.bofh.it>
I have done additional research, and it now appears that programs that do extensive disk writes run much slower (3-6x) in Bookworm than they did in Bullseye.  The two cases I have observed are 'svnadmin dump', and extracting an SQL backup of a Bacula database from Postgresql (backup file about 3 GB).  Operations that perform extensive reads (a Bacula backup operation to magnetic tape, 600 GB) seem to run at the same speed as before.

At the moment, this is a 32-bit PAE system.  I don't know of an obvious reason why that would matter.  At the time of the upgrade, the system memory was enlarged from 16 to 32GB, in anticipation of converting the system from i386 to amd64.

Suggestions for tracking this down would be welcome.

Ken


Sent: Thursday, August 10, 2023 12:04 PM
To: 'debian-user@lists.debian.org'
Subject: svnadmin dump much slower in Bookworm

A set of svnadmin dump commands that run as part of a backup procedure seem to be _much_ slower in Bookworm than in Bullseye.  Prior to the upgrade to Bullseye, these commands took slightly less than one hour.  After the upgrade, similar commands (dumping a few more revisions) require more than six hours.  The script that performs these commands has not been changed.  Has anyone else seen this problem?

Thanks,

Ken
 
 

[toc] | [next] | [standalone]


#260945

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2023-08-15 04:10 +0200
Message-ID<H2RFn-1Wch-1@gated-at.bofh.it>
In reply to#260943
> I have done additional research, and it now appears that programs that do
> extensive disk writes run much slower (3-6x) in Bookworm than they did in
> Bullseye.  The two cases I have observed are 'svnadmin dump', and extracting
> an SQL backup of a Bacula database from Postgresql (backup file about 3 GB).
> Operations that perform extensive reads (a Bacula backup operation to
> magnetic tape, 600 GB) seem to run at the same speed as before.
>
> At the moment, this is a 32-bit PAE system.  I don't know of an obvious
> reason why that would matter.  At the time of the upgrade, the system memory
> was enlarged from 16 to 32GB, in anticipation of converting the system from
> i386 to amd64.

FWIW, I've had very serious write performance issues on my Thinkpad T61
(8GB RAM + SSD) when using a 32bit PAE kernel (occasionally below 1MB/s,
tho not reliably reproducible, e.g. not right after boot).

Those problems disappeared when I switched to an amd64 kernel (while
keeping the userland 32bit).

https://serverfault.com/questions/996495/writes-throttled-to-500kb-s

Your symptoms seem quite different, but with 16GB of RAN, I'd strongly
suggest you try an amd64 kernel, just in case.


        Stefan

[toc] | [prev] | [next] | [standalone]


#260947

FromMax Nikulin <manikulin@gmail.com>
Date2023-08-15 04:40 +0200
Message-ID<H2S8p-1WsK-3@gated-at.bofh.it>
In reply to#260943
On 15/08/2023 04:56, kjohnson@eclypse.org wrote:
> I have done additional research, and it now appears that programs that
> do extensive disk writes run much slower (3-6x) in Bookworm than they
> did in Bullseye.

Have you compared kernel IO schedulers? May it be a case of SSD vs HDD 
optimizing?

grep '' /sys/block/*/queue/scheduler

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web