[BlueOnyx:19687] Re: Updated CMU published
Richard Morgan :: Morgan Web
richard at morgan-web.co.uk
Fri Jun 10 06:57:34 -05 2016
Thank you for this Michael.
Just one thing to report is that pigz is causing one of our servers to
almost grind to a halt.
This older, lowish spec (Dell R200, 4Gb) server mostly serves image files so
there is a lot of data which doesn't compress that well. This was previously
fine but yesterday and today there was an outage. Is there an option
available to preserve the previous behaviour?
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1144 root 16 0 35440 2936 464 S 50.9 0.1 4:45.61 pigz
16667 mysql 15 0 152m 20m 3752 S 2.0 0.6 593:16.48 mysqld
1 root 15 0 2172 360 332 S 0.0 0.0 8:57.75 init
2 root RT -5 0 0 0 S 0.0 0.0 1:34.59 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 10:11.54 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.01 watchdog/0
Thanks, Richard
-----Original Message-----
From: Blueonyx [mailto:blueonyx-bounces at mail.blueonyx.it] On Behalf Of
Michael Stauber
Sent: 09 June 2016 00:49
To: BlueOnyx General Mailing List
Subject: [BlueOnyx:19669] Updated CMU published
Hi all,
One of the more complex pieces of code we are maintaining is CMU - our
Cobalt Migration Utility. It had fallen into a slightly deplorable state. It
was still mostly working, but while doing so it was groaning, moaning and
bitching. No more of that!
The following fixes and improvements were made:
Speed:
=======
We all know a CMU-Export (and import) can take its sweet time. Walzing
through all those tarballs? That's slow. Especially if there is lots of
data. The tarballs CMU generates for Vsites and Users are regular TAR
archives packed with Gnuzip. TAR is relatively fast, but the Gnuzip part is
what takes the longest.
For that reason we now switched CMU to use the command line utility 'pigz'
to compress the tarballs. Mind you: This is still in Gnuzip format. So it
can be unpacked with regular Gnuzip and is 1:1 compatible.
It's just that 'pigz' is multiprocessor capable and will use all available
CPU cores for parallel processing of the compressed archive.
The speed increase this provides naturally depends on a lot of factors.
Like how many CPU cores your server has available and also how good (or
bad) your files can be compressed.
But I've seen speed increases between 5-10 times for a regular CMU-Export
during testing. \o/
The CMU-Import now also goes considerably faster than before, as it also
uses 'pigz' when unpacking the tarballs.
Bugfixes:
=========
- The warning message "Subroutine Compress::Zlib::gzFile::gzseek
redefined" is now gone.
- Helptexts for cmuExport and cmuImport (available via "-h" parameter)
have been cleaned up and clarified.
- Incorrect helptext for cmuImport parameter "-s" corrected. It is now
"import server-admins (Resellers)" as it should be.
- Various quota related issues improved and fixed. In the past you
would sometimes get some weird characters on the screen if a
cmuImport did run into quota issues. This will no longer happen.
- Various other fixes.
Summary:
========
Both a cmuExport and a cmuImport should now be a much faster and much
cleaner experience than before.
There are still a few identified and open issues, which we will address in
future CMU updates. Such as the current inability to cmuImport subdomains.
Another room for improvement is the direct export/import of DNS and MySQL
via CMU, which will be added in the close future. As is both DNS and MySQL
must be exported/imported separately via the methods explained in our
Migration Guide.
The updated CMU is available as YUM update for all versions of BlueOnyx.
--
With best regards
Michael Stauber
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
More information about the Blueonyx
mailing list