From: Phillip S. <ps...@cf...> - 2011-06-02 02:40:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dump throughput seems to suffer significantly because each of the 3 slaves are simultaneously trying to read from the disk, causing unnecessary seeking. I'm a little unsure of how to fix the problem though. Right now, each slave reads the data blocks, then optionally compresses, then waits for the signal from the previous slave to write it to the output. Instead, I think it needs to be signaled when it is time to start reading, do the reading, signal the next slave to read, optionally do the compression, then wait to be signaled to do the writing. That way multiple slaves can be compressing at the same time, but only one can be reading or writing at a time. Right now it uses SIGUSR2 to notify the next slave to proceed, but two signals can not be queued at the same time. Should it also use SIGUSR1 for the other signal, or is there a better way than signals to notify the next slave to proceed? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3m+CEACgkQJ4UciIs+XuK9RQCeKwhAP/2p04E0SXIKK31aHpQm ookAoIniqonMY1/Z8Cl6LrOqHVXMu2M7 =IE+2 -----END PGP SIGNATURE----- |
From: Phillip S. <ps...@cf...> - 2011-06-02 14:57:25
Attachments:
serialize-reads.patch
|
I have managed to come up with a test patch to have the slaves use SIGUSR1 to signal the next slave to start the read phase, and continue to use SIGUSR2 to start the write phase. This has resulted in double the throughput in my initial test, taking the time it takes to dump ( to /dev/zero ) a 6.9/22gb fs with 386988 inodes from 6 minutes 15 seconds to 3 minutes 3 seconds. |
From: Phillip S. <ps...@cf...> - 2011-06-03 15:45:04
|
On 6/2/2011 10:57 AM, Phillip Susi wrote: > I have managed to come up with a test patch to have the slaves use > SIGUSR1 to signal the next slave to start the read phase, and continue > to use SIGUSR2 to start the write phase. This has resulted in double the > throughput in my initial test, taking the time it takes to dump ( to > /dev/zero ) a 6.9/22gb fs with 386988 inodes from 6 minutes 15 seconds > to 3 minutes 3 seconds. That test was done on a duplicated fs. Because it was recently duplicated for testing purposes, it had fairly low fragmentation. I decided to do some further tests, starting with the original aged and fragmented filesystem. All tests done using -b 1024 after dropping cache. Without patch: 18m 48s With patch: 8m 35s When using compression ( -z, old slow single core cpu ) on the duplicate (defragged) fs: Without patch: 8m 51s With patch: 9m 55s When using compression ( -z ) on the original fs: Without patch: 20m 51s ( 8m 5s cpu time ) With patch: 13m 52s ( 9m 12s cpu time ) When using compression and writing the output to an actual file instead of /dev/zero, on the duplicate fs: Without patch: 9m 41s With patch: 10m 12s And on the original fs: Without patch: 23m 22s With patch: 15m 55s Time to duplicate the original fs using dump | restore: Without patch: 34m 50s With patch: 25m 35s I have no idea why the patch seems to cause a slight slow down when using compression on the defragged fs, but a significant speed up otherwise. |
From: Stelian P. <st...@po...> - 2011-06-10 12:43:58
|
Hi Phillip, On Thu, Jun 02, 2011 at 10:57:16AM -0400, Phillip Susi wrote: > I have managed to come up with a test patch to have the slaves use > SIGUSR1 to signal the next slave to start the read phase, and > continue to use SIGUSR2 to start the write phase. This has resulted > in double the throughput in my initial test, taking the time it > takes to dump ( to /dev/zero ) a 6.9/22gb fs with 386988 inodes from > 6 minutes 15 seconds to 3 minutes 3 seconds. [...] I've commited your patch in CVS. This was done post-0.4b44, so it will take a while before going out in a "stable" release, so we should have plenty of time to test if something broke. Thanks! Stelian. -- Stelian Pop <st...@po...> |
From: Phillip S. <ps...@ub...> - 2012-07-10 20:36:32
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/10/2011 8:43 AM, Stelian Pop wrote: > I've commited your patch in CVS. > > This was done post-0.4b44, so it will take a while before going out > in a "stable" release, so we should have plenty of time to test if > something broke. I noticed in the CHANGES file you wrote: Improve data throughput when using compression in dump by allowing multiple slaves to compress in parallel. Thanks to Phillip Susi <ps...@cf...> for the patch. Compression was already done in parallel, what I did was make the reading NOT be done in parallel because that usually slows things down. I have noticed that on a well aged and fragmented filesystem, the old way can be a little faster, I presume because the IO is more random and having multiple slaves generating IO concurrently gives the IO elevator more to work with so it can derandomize it some. On two unrelated notes: 1) I was wondering if you might consider upgrading to a modern VCS; CVS is just terrible. 2) I noticed that http://dump.sourceforge.net/ still says that the latest release is 0.4-b43. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP/JJIAAoJEJrBOlT6nu752NkH/1q8rSsy8m7iU13eQ+C0n3ad gisaXFxTP+9/NeoxlXU9pUTcSxWvYqNCmEoDJrPVV/4klXex4IA0YGl8bPXT0Txc R3gfdzHGgeMVta+Er6A1akchokrmgLtBc/q1wu91yd+E2BxQtxeu2QYFN90tkK4I n+ls5GqMoSDQ+AdUUlW78o6o2zIV3I8ZcgIMBqB/GXY5CoNSV05+4/KmHLmEusIP axlz0lsamtsLcS3y2wMugwD8eFTRgp1oZdpSGJ8+Xfe1zd+GFwA4YJqK4Qs2OGsX NE1C8yzSv+WnyyCF+SkiVeywuRatlHCNSGeXaKhW1+a7EF4yQf7t+z1KtFqpFpc= =nsMF -----END PGP SIGNATURE----- |