Как понять в каком месте завис Perl скрипт?

Берем вот этот скрипт: https://raw.githubusercontent.com/ahiguti/gdbperl/master/gdbperl.pl

Стягиваем gdb: yum install -y gdb

Получаем нечто вот такое:

perl gdbperl.pl 755934
command:
gdb -silent -nw /usr/bin/perl 755934

environ:
SHELL=/bin/sh
MAILTO=root
USER=root
PATH=/usr/bin:/bin
PWD=/root
SHLVL=1
HOME=/root
LOGNAME=root
_=/usr/bin/fastvz_backup.pl

c_backtrace:
#0  0x0000003f7540da70 in __read_nocancel () from /lib64/libpthread.so.0
#1  0x0000003f774f0990 in PerlIOUnix_read () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#2  0x0000003f774f5055 in PerlIOBuf_fill () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#3  0x0000003f774ef848 in Perl_PerlIO_fill () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#4  0x0000003f774f4cbf in PerlIOBase_read () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#5  0x0000003f774f4dfb in PerlIO_getc () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#6  0x0000003f774a29b0 in Perl_sv_gets () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#7  0x0000003f7748dbd3 in Perl_do_readline () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#8  0x0000003f7748a37e in Perl_runops_standard () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#9  0x0000003f774380ba in perl_run () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#10 0x00000000004017bc in main ()

perl_backtrace:
[5] Tool::get_backups_list("7xxxxx", "xxx", "7549") <- /usr/local/lib/perl/FastBackup.pm:253(FastBackup)
[4] Tool::get_last_full_backup_info("xxxx", "xxxx", "7549") <- /usr/bin/fastssad.pl:268(main)
[3] (other) <- /usr/bin/faxxx.pl:266(main)
[2] (loop) <- /usr/bin/fasxxxxx.pl:224(main)
[1] main::function() <- /usr/bin/faxxxx.pl:156(main)

Источник: http://www.slideshare.net/hirose31/inspect-runningperl

Странные проблемы rsync при работе с флагом -z

Итак, есть 16 Гб крупным бинарным файлом.

Пробуем перелить его силами rsync без флага -z:

time rsync -a --progress /vz/private/1210 root@technode4.fv.ee:/tmp/1210

Потребление процессора разумное (32%):

395053 root      20   0  106m 1500  988 R 32.3  0.0   0:06.84 rsync                                                         

Итоги:

sent 16906158370 bytes  received 96 bytes  103 401 580.83 bytes/sec
total size is 16904094532  speedup is 1.00
real 2m42.437s
user 1m23.115s
sys 0m38.441s

Пробуем перелить с флагом -z:

time rsync -az --progress /vz/private/1210 root@technode4.fv.ee:/tmp/1210

Сразу в процессе видно, что скорость падает с 100 мегабайт/секунду до 20, а rsync начинает висеть вот в таком мерзком виде в top (да, да, он целиком выедает ядро процессора): 

391791 root      20   0  106m 1812 1020 R 99.7  0.0   0:54.36 rsync   

В итоге пришлось прервать процесс, так как он не завершился бы в разумные сроки - половина скопировалось лишь за 5 минут и скорость упала до 5 мегабайт/секунду:

real 5m54.894s
user 4m24.249s
sys 0m20.234s

В итоге данные в лучшем случае перелились бы за 10-20 минут, что уже в 4-5 раз хуже, чем вариант без использования сжатия.

Почеум так? Сжатие силами протокола gzip довольно требовательно к процессору и очень быстро упирается в производительность одного ядра, которая даже на топовых процессорах очень слабая.

Сжатие, безусловно, даст ускорение передачи данных, но лишь в случае, когда процессор будет успевать сжимать данные быстрее, чем выдерживает канал связи, этого можно достичь, например, используя внешнее сжатие через парраллельный компрессор pigz.

Утилита для монтирования OpenVZ ploop дисков на любой машине с Linux

Предлагаю к Вашему вниманию очередную разработку нашей компании: ploop userspace. Это утилита для монтирования дисков в формате ploop, которые используются системой виртуализации OpenVZ.

Поддерживаются оба формата хранения - v1 и v2. Поддержка записи не планируется в виду высокой сложности задачи.

Прошу: GitHub