Сборка GNU parallel для CentOS/RHEL

Проще некуда:

cd /usr/src
wget http://ftp.gnu.org/gnu/parallel/parallel-latest.tar.bz2
tar -xf parallel-latest.tar.bz2
cd parallel-20140722/
./configure --prefix=/opt/parallel
make install
/opt/parallel/bin/parallel

А еще - Parallel написан на Perl и сборки-то в общем не требует.

Сравнение скорости работы хэш функций между OpenSSL 1.0.1e-fips 11 Feb 2013 (CentOS 6) и OpenSSL 1.0.2 beta 2

Платформа для тестов - Intel E5 2670v2. Объем файла - 15Гб. Объем озу на машине - 128 Гб.

Выкручиваем все процессоры на полную частоту:

cpufreq-set -g performance
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Объем тест-файла: 15GB

Прогреваем кэш:

cat /vz/private/61350/root.hdd/root.hdd  >/dev/null

Скорость после прогрева страничного кэша:

 cat /vz/private/61350/root.hdd/root.hdd |pv >/dev/null
12,4GB 0:00:06 [2,07GB/s] [              <=>       

Тестовая строка:

for hash in md4 md5 sha1 sha256 sha512; do echo "$hash"; for i in `seq 1 3`; do time cat root.hdd | taskset -c 31 openssl $hash >/dev/null;done; echo ""; done 

 Итак, результаты для 1.0.1e-fips 11 Feb 2013 (я привожу только 1 результат из 3х запусков, так как данные очень близки и находятся в пределах 2-4% погрешности):

md4
real    0m19.018s
user    0m16.216s
sys    0m11.192s

md5
real    0m28.764s
user    0m25.793s
sys    0m12.040s

sha1
real    0m31.177s
user    0m28.992s
sys    0m11.336s

sha256
real    1m10.431s
user    1m8.714s
sys    0m10.995s

sha512
real    0m48.131s
user    0m45.186s
sys    0m12.097s

А вот результаты для OpenSSL 1.0.2 beta 2, в которой активно используются Intel SHA Extenstions:

md4
real    0m18.442s
user    0m15.761s
sys    0m10.678s

md5
real    0m28.571s
user    0m25.242s
sys    0m12.126s


sha1
real    0m30.228s
user    0m28.214s
sys    0m11.128s


sha256
real    0m56.517s
user    0m53.637s
sys    0m12.123s


sha512
real    0m43.056s
user    0m41.083s
sys    0m11.252s

Итак, выводы по скорости.

md4, md5 - без изменений, что ожидаемо - каких-либо серьезных оптимизаций алгоритмов не производилось.

sha1 - без изменений  несмотря на оптимизации за счет Intel SHA Extenstions. 

sha256 - стал быстрее на 15 секунд! Ура, оптимизация дала эффект :)

sha512 - стал быстрее на 5 секунд. Неплохо, вполне неплохо :)

Выводы - оптимизация дала плоды, но до кардинальных изменений в скорости очень далеко.

Эффективность от использования Intel Sha Extensions при использовании хэширования в OpenSSL

Это очень крутая штука в наборе инструкций современных процессоров Intel. Но чтобы задействовать это ускорение приложение, разумеется, должно использовать специальные ассемблерные команды. И примером приложения использующего их является OpenSSL версии начиная с 1.0.2beta2 и хэш алгоритмы SHA-1 / SHA-512, другие хэш функции не смотря на поддержку со стороны процессоров таким образом оптимизированы не были (видимо, по причине известных проблем с коллизиями в том же  md5).

Итак, берем машины E5 2670v2 из тестового стенда и прогоняем обычный OpenSSL (OpenSSL 1.0.1e 11 Feb 2013 из сборки Debian Wheezy) в следующей конфигурации:

for i in md4 md5 sha1 sha256 sha512; do openssl speed $i 2>&1|egrep -v '(Doing|OpenSSL|built|options|compiler)';done

И получаем вот такие цифры:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              79469.84k   247447.81k   593828.73k   909654.02k  1081913.88k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              57183.56k   170794.37k   383938.70k   555845.63k   640581.52k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             63621.49k   183943.89k   404654.92k   581348.35k   689886.95k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           49298.04k   111948.78k   193886.12k   240399.93k   256172.03k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha512           39788.22k   163034.65k   244865.02k   346445.91k   395853.82k

Как обычно бывает - md4 самый быстрый и тем ярче превосходство, чем больше блок данных (особенно велико оно на кратных 8192 байтам блоках).

Теперь собираем вручную OpenSSL версии равной или старше чем openssl-1.0.2-beta2.

И запускаем те же тесты используя свеже собранный OpenSSL на Debian 7 Wheezy:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              45183.93k   159576.92k   445669.20k   805581.82k  1057753.77k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              37000.35k   125855.38k   312857.60k   516176.14k   630956.03k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             41862.74k   134170.77k   343537.27k   562741.59k   701120.13k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           62982.42k   140178.79k   245336.79k   300390.40k   322792.20k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha512           45197.99k   180312.43k   280480.11k   396773.03k   453845.02k

Теперь повторяем тест стандартного OpenSSL но уже из состава CentOS 6 (OpenSSL 1.0.1e-fips 11 Feb 2013):

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              60064.70k   188973.95k   447881.22k   683383.58k   808962.73k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              44789.97k   131985.83k   293138.94k   420840.19k   483939.67k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             48999.05k   139180.74k   304883.92k   442452.99k   521759.40k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           36892.66k    82828.82k   144455.59k   181290.18k   194063.02k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha512           29594.76k   119322.73k   185533.70k   262828.03k   299693.84k

А теперь прогоняем тест актуальной версии OpenSSL собранной вручную, но на машине на базе CentOS 6:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              29176.77k   102947.75k   300172.54k   573421.63k   785858.56k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              25097.23k    83432.96k   220905.47k   375433.44k   474740.05k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             27111.94k    89276.33k   238348.20k   409880.32k   526125.74k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           48053.63k   107633.37k   186195.20k   227252.14k   243523.58k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha512           34854.11k   141876.76k   215300.10k   301368.30k   342690.47k

Тесты в обоих версиях были прогнаны 3-5 раз, значения отличались не более чем на  1000k, что в районе 1-2% погрешности и вполне допустимо.

Выводы очень странные напрашиваются. Точно ускоряется и очень мощно sha256 - в почти 1,5 раза.

Почему замедляются md4 и md5 - для меня загадка.  Возможно это связано с флагами компиляции данных пакетов в Debian 7 Wheezy либо с деградациями в beta выпуске OpenSSL либо просто с большими отклонениями на малом объеме данных - на 8192 блоках таких колебаний вовсе нету.

А sha1 в свою очередь в любом случае показал себя как самый быстрый хэш из хэшей со вменяемыми характеристиками и стойкостью к коллизиям! :)

Ускорение хэширования, криптографии, а также сжатия силами Intel Quick Assist

У Intel на базе процессоров Intel E5 2600й серии v2 есть такая крутая отдельная плата - как Intel QuickAssist Technology,  которая в свою очередь включает ускорение ряда хэш функций SHA-1, MD5; SHA-2 [SHA-224, SHA-256, SHA-384, SHA-512. А также сжатия и криптографии!

Сборка OpenSSL актуальной версии на CentOS 6

Ставим зависимости:

yum install -y gcc make perl 

Все довольно просто за исключением того, что система сборки на Перле:

cd /usr/src
wget https://www.openssl.org/source/openssl-1.0.2-beta2.tar.gz
tar -xf openssl-1.0.2-beta2.tar.gz
cd  openssl-1.0.2-beta2/
./config --prefix=/opt/openssl --openssldir=/opt/openssl/openssldir
make
make install

Если установка не требуется, то можно запустить утилиты вручную:

./apps/openssl version

Тестирование скорости хэш функций реализованных в OpenSSL на процессорах семейства Xeon E5 26XX

Вот так запускать тесты:

for i in md4 md5 sha1 sha256 sha512; do openssl speed $i 2>&1|egrep -v '(Doing|OpenSSL|built|options|compiler)';done

Вот такие результаты вышли у меня (OpenSSL 1.0.1e-fips 11 Feb 2013, CentOS 6):

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              68566.14k   173477.65k   515525.95k   677865.49k   931820.76k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              40919.27k   133902.74k   332599.15k   487704.31k   560110.13k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             53991.04k   156746.65k   345242.72k   502931.07k   572807.73k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           35243.93k    91730.62k   165080.62k   193792.86k   213022.14k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha512           33810.13k   135413.99k   174028.97k   296263.47k   345636.64k

 Почему такие странности? Ой, а какие странности? Например, то, что SHA1 быстрее чем md5, что довольно неожиданно.

Беглый анализ кода OpenSSL (1.0.2.beta2) дает такие вот хитрые ответы:

• md-4 написан исключительно на C.
• md-5 использует ассемблерные оптимизации для 86_64,  i586, но НЕ использует SIMD инструкции SSE.
• sha-1 использует ассемблерные оптимизации под почти все популярные архитектуры.  Кроме этого, имеет оптимизации на SSE3, Intel AVX,  а также на Intel SHA Extensions.
• sha-256 использует ассемблерные оптимизации и немного SIMD инструкций, но без особого фанатизма, судя по коду.
• А вот sha-512 также очень тщательно оптимизирован по аналогии с sha-1.

Профилирование приложений на Golang

К сожалению, сабж весьма скудно документирован, но при этом снабжен очень крутым набором инструментов! Основной источник: http://blog.golang.org/profiling-go-programs

Мы сейчас говорим исключительно о профайлинге по потреблению CPU. Для начала нужно добавить в программу следующее:

import "runtime/pprof"
import "flag"
import "log"

 Потом добавляем в функцию main в самом начале:

 flag.Parse()
    if *cpuprofile != "" {
        f, err := os.Create(*cpuprofile)
        if err != nil {
            log.Fatal(err)
        }  
        pprof.StartCPUProfile(f)
        defer pprof.StopCPUProfile()
    }   

И запускаем программу со следующими аргументами:

./gordiff -cpuprofile=gordiff.prof

Запускаем профайлер:

go tool pprof gordiff gordiff.prof

Смотрим результаты введя в его терминале команду top10:

(pprof) top10
Total: 426 samples
     338  79.3%  79.3%      338  79.3% code.google.com/p/go.crypto/md4._Block
      57  13.4%  92.7%       57  13.4% main.faster_rollsum
      21   4.9%  97.7%       21   4.9% syscall.Syscall
      10   2.3% 100.0%       10   2.3% runtime.memmove
       0   0.0% 100.0%       21   4.9% System
       0   0.0% 100.0%       10   2.3% bufio.(*Reader).Read
       0   0.0% 100.0%      338  79.3% code.google.com/p/go.crypto/md4.(*digest).Write
       0   0.0% 100.0%      405  95.1% main.generate_signature
       0   0.0% 100.0%      405  95.1% main.main
       0   0.0% 100.0%      405  95.1% runtime.gosched0

 

Реализация утилиты rdiff на чистом Python

Прошу:

cd /usr/src
git clone git@github.com:therealmik/pyrdiff.git --branch python2
cd pyrdiff

Кому понравилось, идем на репо и ставим плюсик: https://github.com/therealmik/pyrdiff

Сборка librsync с репо на GitHub

Дадада! Rsync оживает и оживление началось с переноса проект на GitHub! 

cd /usr/src
git clone https://github.com/librsync/librsync.git
cd librsync
yum install -y autoconf automake libtool popt-devel popt
./autogen.sh
./configure --prefix=/opt/rdiff
make install

Вы не умеете бэкапить Ваши данные!

Данный заголовок касается Вас, если Вы ежедневно копируете от 100 гигабайт данных и это не базы данных.

Также этот пост касается Вас, если Вы бэкапите ploop контейнеры в OpenVZ.

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

К чему это может привести? К деградации производительности. Из памяти вытесняются файлы, которые реально атм должны быть!

Как это диагностировать? http://www.stableit.ru/2014/07/linux-page-cache.html

Насколько все плохо было в моих тестах? Это была OpenVZ нода с большим числом ploop контейнеров.

total cached size: 72,771,035,136

Да, да! 72 гигабайта оперативной памяти через почти сутки после бэкапа были забиты бэкапным хламом, а не реальными данными.

Что делать? Использовать прослойку, которая подключает использование O_DIRECT при чтении данных (в таком случае даннные НЕ будут помещены в страничный кэш вообще). Например, я написал такую: https://github.com/FastVPSEestiOu/cat_cache_safe Она, конечно, пока медленнее обычного cat, но зато не засоряет страничный кэш вообще.

Так что Вы можете сделать вот так: ./cat_cache_safe| tar -cpzf /place_to_archive.tar.gz - и тем самым вы избежите от помещения прочтенных данных в страничный кэш. А вот с помещением туда записанных данных все весьма сложно, поэтому я рекомендую бэкапиться вообще на удаленный сервер! Так и безопаснее и не создается лишняя нагрузку на запись на локальную дисковую систему.

Как посмотреть, какие файлы размещены в Linux Page Cache (блок cached во free/top)?

Вот так, тулзой fincore: https://code.google.com/p/linux-ftools/

Собрать ее можно так (на CentOS 6 собирается без проблем):

cd /usr/src
mkdir linux-ftools
cd linux-ftools
wget https://linux-ftools.googlecode.com/archive/2a7918d4b81b3cbbd6d7a1087b907ba346fd8338.tar.gz -Olinux-ftools.tar.gz
tar -xf linux-ftools.tar.gz
 cd linux-ftools-*
 ./configure --prefix=/opt/linux-ftools
make
make install

Использовать вот так:

/opt/linux-ftools/bin/linux-fincore --pages=false --summarize --only-cached `find /test_path -type f |perl -e 'do{chomp; print "$_ "} for <>'`
filename                                                                                       size        total_pages    min_cached page       cached_pages        cached_size        cached_perc
--------                                                                                       ----        -----------    ---------------       ------------        -----------        -----------
/vz/private/1231/root.hdd/root.hdd                                                   95,808,389,120         23,390,720                  0          9,838,415     40,298,147,840              42.06
---
total cached size: 40,298,147,840

Реализация инкрементальных бэкапов на ZFS

http://breden.org.uk/2008/05/12/home-fileserver-backups-from-zfs-snapshots/

Как сравнить поблочно два блочных устройства?

Утилитой CMP:

LANG=C cmp /dev/ploop41029 /dev/nbd0
/dev/ploop41029 /dev/nbd0 differ: char 1049613, line 1

Скорость работы tinyproxy

Ну очень медленно :)

На гигабитном канале:

 0% [                                                                                                        ] 139 650 584  599K/s  ост 30h 9m  ^C

Вы с вероятностью 90% НЕ знаете, как работает Интернет

Хотите подробностей? Хотите правда понять? Вот отличная книга для начала: http://www.ozon.ru/context/detail/id/26326082/