Stable IT

Thursday, 28 August 2014

Что делать если atop показывает не все сетевые интерфейсы?

То нажмите l в окне atop, потом прощелкайте Enter до - Maximum lines for interface statistics и забивайте там нужное число, например - 10.

Самый удобный и просто метод посчитать pps (число пакетов-секунду) на интерфейсе

Отсюда: https://gist.github.com/pavel-odintsov/0a26894e7e93aa25902e

Как починить падения Puppet DB от ошибок OOM killer?

Проявляется бага как:

Warning: Error 400 on SERVER: Could not retrieve facts for ovz14.fastvps.ru: Failed to submit 'replace facts' command for ovzxxx.ru to PuppetDB at xxxxxx:8081: Connection refused - connect(2)
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for oxxxxs.ru to PuppetDB at xxxxx:8081: Connection refused - connect(2)

В логе (/var/log/puppetdb/puppetdb-daemon.log ) при этом:

# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError="kill -9 %p"
# Executing /bin/sh -c "kill -9 15190"...
java.lang.OutOfMemoryError: Java heap space
Dumping heap to /var/log/puppetdb/puppetdb-oom.hprof ...
Heap dump file created [225222767 bytes in 1,713 secs]

Чиним, открываем конфиг: /etc/sysconfig/puppetdb и там заменяем Xmx192m на Xmx1024m.

Применяем:

/etc/init.d/puppetdb restart

Убеждаемся, что Java завелась с новым лимитом памяти:

ps aux|grep Xmx -i --color
puppetdb 29429 11.7 1.8 1654504 593832 ? Sl 11:35 0:26 /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx1024m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/puppetdb/puppetdb-oom.hprof -Djava.security.egd=file:/dev/urandom -cp /usr/share/puppetdb/puppetdb.jar clojure.main -m com.puppetlabs.puppetdb.core services -c /etc/puppetdb/conf.d

Monday, 25 August 2014

perf trace - эффективная замена strace в ряде случаев!

perf trace /bin/echo "Php suxx"
   0.000 ( 0.000 ms): ... [continued]: read()) = 0
Problems reading syscall 59(execve) information
   0.288 ( 0.000 ms): ... [continued]: execve()) = 0
Php suxx
   0.304 ( 0.001 ms): brk(brk: 0 ) = 9400320
   0.320 ( 0.002 ms): mmap(addr: 0, len: 4096, prot: 3, flags: 34, fd: 4294967295, off: 0 ) = -1309794304
   0.329 ( 0.005 ms): access(filename: 140268025023360, mode: 4 ) = -1 ENOENT No such file or directory
   0.337 ( 0.003 ms): open(filename: 140268025016833, flags: 0, mode: 1 ) = 3
   0.340 ( 0.001 ms): fstat(fd: 3, statbuf: 140735595271856 ) = 0
   0.343 ( 0.003 ms): mmap(addr: 0, len: 32186, prot: 1, flags: 2, fd: 3, off: 0 ) = -1309827072
   0.345 ( 0.001 ms): close(fd: 3 ) = 0
   0.355 ( 0.003 ms): open(filename: 140268027119178, flags: 0, mode: 0 ) = 3
   0.357 ( 0.002 ms): read(fd: 3, buf: 140735595272280, count: 832 ) = 832
   0.361 ( 0.001 ms): fstat(fd: 3, statbuf: 140735595271936 ) = 0
   0.366 ( 0.003 ms): mmap(addr: 0, len: 3750152, prot: 5, flags: 2050, fd: 3, off: 0 ) = -1315766272
   0.371 ( 0.004 ms): mprotect(start: 140268022771712, len: 2093056, prot: 0 ) = 0
   0.376 ( 0.004 ms): mmap(addr: 140268024864768, len: 20480, prot: 3, flags: 2066, fd: 3, off: 1613824) = -1312055296
   0.382 ( 0.003 ms): mmap(addr: 140268024885248, len: 18696, prot: 3, flags: 50, fd: 4294967295, off: 0) = -1312034816
   0.386 ( 0.001 ms): close(fd: 3 ) = 0
   0.396 ( 0.002 ms): mmap(addr: 0, len: 4096, prot: 3, flags: 34, fd: 4294967295, off: 0 ) = -1309831168
   0.401 ( 0.002 ms): mmap(addr: 0, len: 4096, prot: 3, flags: 34, fd: 4294967295, off: 0 ) = -1309835264
   0.405 ( 0.001 ms): mmap(addr: 0, len: 4096, prot: 3, flags: 34, fd: 4294967295, off: 0 ) = -1309839360
   0.407 ( 0.001 ms): arch_prctl(option: 4098, arg2: 140268027086592, arg3: 140268027080704, arg4: 34, arg5: 4294967295) = 0
   0.459 ( 0.003 ms): mprotect(start: 140268024864768, len: 16384, prot: 1 ) = 0
   0.467 ( 0.002 ms): mprotect(start: 140268027129856, len: 4096, prot: 1 ) = 0
   0.472 ( 0.004 ms): munmap(addr: 140268027092992, len: 32186 ) = 0
   0.531 ( 0.001 ms): brk(brk: 0 ) = 9400320
   0.534 ( 0.002 ms): brk(brk: 9535488 ) = 9535488
   0.545 ( 0.005 ms): open(filename: 140268022569584, flags: 0, mode: 140268024885264 ) = 3
   0.547 ( 0.001 ms): fstat(fd: 3, statbuf: 140268024885312 ) = 0
   0.552 ( 0.003 ms): mmap(addr: 0, len: 99158576, prot: 1, flags: 2, fd: 3, off: 0 ) = -1414926336
   0.555 ( 0.001 ms): close(fd: 3 ) = 0
   0.577 ( 0.001 ms): fstat(fd: 1, statbuf: 140735595273776 ) = 0
   0.580 ( 0.002 ms): mmap(addr: 0, len: 4096, prot: 3, flags: 34, fd: 4294967295, off: 0 ) = -1309798400
   0.587 ( 0.004 ms): write(fd: 1, buf: 140268027121664, count: 9 ) = 9
   0.592 ( 0.001 ms): close(fd: 1 ) = 0
   0.596 ( 0.003 ms): munmap(addr: 140268027121664, len: 4096 ) = 0
   0.599 ( 0.001 ms): close(fd: 2 ) = 0
0.602 ( 0.000 ms): exit_group(error_code: 0

Thursday, 14 August 2014

CPULIMIT, CPUUNITS и CPUS - детальное тестирование и описание параметров управляющих нагрузкой на CPU со стороне контейнеров OpenVZ

Выводы в самом конце - листайте :)

Тестовая среда: 2.6.32-042stab090.5, в контейнерах: Debian-7-x86_64 minimal. Процессор: 3.4 Ghz, число ядер: 8

На ноде выставлен режим максимальной частоты:

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

На машине 8 ядер

Два контейнера - 101 и 102, им по дефалту выдано: CPUUNITS="1000" CPUS/CPULIMIT не использованы.

Изучение поведения шедулера OpenVZ:

1) Запускаем stress --cpu 8 на первом контейнере:

1 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
2 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
4 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
5 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
6 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
7 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
8 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]

То есть машина получила все доступные ресурсы.

2) Включаем ту же самую команду на второй машине (то есть теперь она включена на обоих). Получаем тоже самое:

1 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
2 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
4 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
5 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
6 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
7 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
8 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]

Но теперь каждый контейнер грузит отдельно ядро не более чем на 50%.

open_vestat показывает следующее:

101: cpu: 50.1 %
102: cpu: 49.8 %

3) Меняем лимиты на 100:

vzctl set 101 --cpuunits 100 --save; vzctl set 102 --cpuunits 100 --save;

И 10000:

vzctl set 101 --cpuunits 10000 --save; vzctl set 102 --cpuunits 10000 --save;

Ничего при этом не меняется! Все ок, важно лишь отношение этих величин
4) Ставим неравные лимиты:

vzctl set 101 --cpuunits 100 --save; vzctl set 102 --cpuunits 200 --save;

И сразу приоритет перешел к машине 101:

101: cpu: 37.2 %
102: cpu: 62.7 %

Схема нагрузки на процы ноды:

1 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
2 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
4 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
5 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
6 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
7 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
8 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]

5) Теперь выдаем каждой машине ровно по 1 логическому ядру, тем самым ограничивая пиковую нагрузку на ядра:

vzctl set 101 --cpus 1 --cpuunits 1000 --save; vzctl set 102 --cpuunits 1000 --cpus 1 --save;

Картина мгновенно меняется - ограничение на число ядер, которое может выедать машина включилось в действие.

1 [ 0.0%]
2 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
3 [ 0.0%]
4 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
5 [ 0.0%]
6 [| 0.7%]
7 [ 0.0%]
8 [ 0.0%]

Разделение как и прежде идеальное:

101: cpu: 49.8 %
102: cpu: 49.8 %

Мегагерцы также выдаются как и ранее:

vzctl exec 101 "cat /proc/cpuinfo|grep Mhz -i"; vzctl exec 102 "cat /proc/cpuinfo|grep Mhz -i";
cpu MHz : 3401.000
cpu MHz : 3401.000

6) Теперь выдаем каждой машине по 2 ядра:

vzctl set 101 --cpus 2 --cpuunits 1000 --save; vzctl set 102 --cpuunits 1000 --cpus 2 --save;

Разделение продолжает быть идеальным:

101: cpu: 49.8 %
102: cpu: 49.8 %

Картина нагрузки следующая:

1 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
2 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
4 [|| 1.3%]
5 [ 0.0%]
6 [ 0.0%]
7 [ 0.0%]
8 [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||99.3%]

7) Вводим параметр cpulimit.
Для машины с 1 логическим процессором поидее поменяться нчиего не должно.

vzctl set 101 --cpus 1 --cpulimit 100 --save; vzctl set 102 --cpulimit 100 --cpus 1 --save;

Ну в общем ничего и не поменялось:

1 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
2 [ 0.0%]
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
4 [ 0.0%]
5 [ 0.0%]
6 [ 0.0%]
7 [ 0.0%]
8 [| 0.7%]

8) Срезаем пиковую нагрузку до 50:

vzctl set 101 --cpus 1 --cpulimit 50 --save; vzctl set 102 --cpulimit 50 --cpus 1 --save;

Несмотря на наличие доступных ресурсов - машины обрезало строго по половине ядра.

1 [||||||||||||||||||||||||||||||| 49.3%]
2 [ 0.0%]
3 [||||||||||||||||||||||||||||||| 49.7%]
4 [ 0.0%]
5 [ 0.0%]
6 [ 0.0%]
7 [ 0.0%]
8 [| 1.3%]

И мегагерцы поменялись:

vzctl exec 101 "cat /proc/cpuinfo|grep Mhz -i"; vzctl exec 102 "cat /proc/cpuinfo|grep Mhz -i";
cpu MHz : 1700.500
cpu MHz : 1700.500

9) Срезаем нагрузку до 10:

vzctl set 101 --cpus 1 --cpulimit 10 --save; vzctl set 102 --cpulimit 10 --cpus 1 --save;

1 [||||||| 9.9%]
5 [ 0.0%]
2 [ 0.0%]
6 [ 0.0%]
3 [ 0.0%]
7 [ 0.0%]
4 [||||||| 10.5%]
8 [| 0.7%]

И тут все работает идеально.

10) отключаем один контейнер, второй оставляем с ограничнием в 10%:

1 [||||||| 9.9%]
5 [|| 1.3%]
2 [ 0.0%]
6 [ 0.0%]
3 [ 0.0%]
7 [ 0.0%]
4 [ 0.0%]
8 [ 0.0%]

И тут все ок!

11) Что будет если сделать --cpulimit 200 при выданном одном процессоре для контейнера? Да ничего плохого - больше 100% он не съест :)

1 [                                                          0.0%]
5 [|                                                         0.7%]
2 [                                                          0.0%]
6 [                                                          0.0%]
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
7 [                                                          0.0%]
4 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
8 [                                                          0.0%]

12) Выдаем двум контейнера по два проца, но при этом жестко ограничиваем нагрузку 100% одного ядра:

vzctl set 101 --cpus 2 --cpulimit 100 --save; vzctl set 102 --cpulimit 100 --cpus 2 --save;

В итоге каждая машина получит по 2 ядра, но по 1.7 Ghz (половина мощности ядра аппаратной ноды):

vzctl exec 101 "cat /proc/cpuinfo|grep Mhz -i"; vzctl exec 102 "cat /proc/cpuinfo|grep Mhz -i";
cpu MHz        : 1700.500
cpu MHz        : 1700.500
cpu MHz        : 1700.500
cpu MHz        : 1700.500

Схема нагрузки будет вот такая:

1 [                                                          0.0%]
5 [|                                                         0.7%]
2 [                                                          0.0%]
6 [                                                          0.0%]
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
7 [                                                          0.0%]
4 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
8 [                                                          0.0%]

13) Выдаем полную нагрузку по обоим ядрам:

vzctl set 101 --cpus 2 --cpulimit 200 --save; vzctl set 102 --cpulimit 200 --cpus 2 --save;

Схема нагрузки меняется мгновенно:

1 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
5 [||                                                        1.3%]
2 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
6 [                                                          0.0%]
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
7 [                                                          0.0%]
4 [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||99.3%]
8 [                                                          0.0%]

14) А если дать одному контейнеру приоритет в два раза:

vzctl set 101 --cpus 2 --cpulimit 200 --cpuunits 100 --save; vzctl set 102 --cpulimit 200 --cpus 2 --cpuunits 200 --save;

То ничего не поменяется, так как нету конкуренции за ресурс - у ноды достаточно ресурсов.

15) Устроим небольшой оверселл по ядрам:

set 101 --cpus 6 --cpulimit 600 --cpuunits 100 --save; vzctl set 102 --cpulimit 600 --cpus 6 --cpuunits 200 --save;

1 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
5 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
2 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
6 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
7 [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||99.3%]
4 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
8 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]

И при этом процессор поделится 1 к 2:

102: cpu: 66.5 %
101: cpu: 33.3 %

16) Теперь рассмотрим интересный кейс - что будет какой контейнер позволит получить больше ресурсов. Контейнер с полным доступом к одному ядру или контейнер с двумя ядрами, но с лимитом суммарной нагрузки 50я % на каждое.

vzctl set 101 --cpus 2 --cpulimit 100 --cpuunits 100 --save; vzctl set 102 --cpulimit 100 --cpus 1 --cpuunits 100 --save;

1 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
5 [                                                          0.0%]
2 [                                                          0.0%]
6 [                                                          0.0%]
3 [                                                          0.0%]
7 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
4 [                                                          0.0%]
8 [||                                                        1.3%]

Разделение при этом будет следующее:

102: cpu: 49.8 %
101: cpu: 49.8 %

Но схема с полным доступом к одному ядру будет предпочтительнее при использовании ПО, которое плохо распараллеливается.

17) Рассмотрим кейс, когда контейнер с большим числом ядер получает меньший вес cpuunits, чем контейнер с меньшим числом ядер

vzctl set 101 --cpus 10 --cpulimit 1000 --cpuunits 100 --save; vzctl set 102 --cpulimit 500 --cpus 5 --cpuunits 200 --save;

Получим полную прогрузку машины:

1 [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||97.4%]
5 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
2 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
6 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
7 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
4 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
8 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]

Приоритет возьмет свое и вторая машина получи ресурсов больше:

101: cpu: 43.4 %
102: cpu: 56.4 %

Но тут нельзя сказать, что получит она ресурсов вдвое больше.

18) Этот пункт я добавил уже после публикации статьи, он исследует кейс поведения, как поведут себя контейнеры с одинаковым CPUUNITS, но разным числом процессоров, выданных контейнеру:

vzctl set 101 --cpus 8 --cpulimit 800 --cpuunits 100 --save; vzctl set 102 --cpulimit 200 --cpus 2 --cpuunits 100 --save;

А поведут они себя вот так (для чистоты эксперимента я запустил по 16 потоков утилиты stress в контейнерах):

101: cpu: 75.0 %
102: cpu: 24.8 %

То есть, контейнер, которому дали большую процессорную мощность получит приоритет в 3-4 раза, как и ожидается. Но стоит обратить внимание, что очень сложно выдать приоритет контейнеру, у которого меньше ресурсов даже силами CPUUNITS.

Иными словами, довольно сложно дать приоритет контейнеру с 1 ядром, когда на ноде есть контейнеры с большим числом выданных ядер.

CPUS

CPUS - задает число логичеcких процессоров, которые доступны контейнеру. Стоит понимать, что если выдать контейнеру 1 ядро, то его производительность будет жестко ограничена мощностью 1 ядра хост-сервера. Даже если на хост-серверер будут свободные ядра - контейнер их использовать не сможет. Это стоит учитывать всегда. Если данный параметр не указан или установлен в нуль - это означает, что контейнер может использовать все ядра хост-сервера.

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

Также параметр CPUS имеет важное значение при использовании параметра CPULIMIT.

CPULIMIT

CPULIMIT - задает максимальную суммарную нагрузку ядер контейнера. Максимально возможная нагрузка контейнера определяется так: N * 100, где N = числу ядер контейнера. То есть, если у контейнера 8 логических процессоров, то максимальное значение CPULIMIT может достигать 800.

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

Если процессоров несколько, то все резко усложняется. Например, если задать CPULIMIT=100 для контейнера с двумя процессорами, то контейнер сможет нагружать каждое из выданных ему ядер не более чем на 50%.

Если же нужно полностью дать контейнеру, скажем, 4 ядра, то ему нужно выдать (4*100) CPULIMIT 400.

Именно этот параметр отображается внутри контейнера как частота виртуального процессора (Mhz /proc/cpuinfo). Частота рассчитывается вот так: HWN_FREQ * CPULIMIT / (100 * N_CPU), где N_CPU - число процессоров, выданных контейнеру. А HWN_FREQ - тактовая максимальная частота 1 ядра ноды. Например, в случае, когда у контейнера 2 ядра и CPULIMIT=100 мы получим: 1/2 HWN_FREQ (1.7 Ghz для моей тестовой ноды с процессором 3.4Ghz)

Лимит этот жесткий, то есть если на аппаратной ноде есть ресурсы, контейнер их не получит. Стоит обращать на это внимание!

CPUUNITS

CPUUNITS - задает отношение выделяемого процессорного времени одному контейнеру к другому. То есть, если задать для двух контейнеров 100 и 200, то второй получит вдвое больше ресурсов. CPUUNITS идеально работает когда контейнеру выдано 1 ядро. Но в случае многопроцессорных контейнеров и серьезной нагрузки на аппаратную ноду эти отношения перестают выполняться честно и второй контейнер будет получать больше ресурсов, чем первый, но не в два раза. Это объясняется особенности шедулера CFQ. Поэтому с разделением ресурсов между контейнерами с большим числом логических процессоров есть довольно серьезные проблемы.

Кого заинтересовала тулза open_vestat - могу поделиться, это скрипт обвязка cgroup на Perl, считает потребление cpu/blkio.time/blkio.sectors и отрисовывает топ10 грузящих контейнеров.

Tuesday, 12 August 2014

Монтирование /tmp на OpenVZ контейнерах в tmpfs

Самое интересное, что монтирование /tmp и прочих специализированных файловых систем осуществляет вовсе не нода, как можно подумать изначально. А сам контейнер. Поэтому в /etc/fstab в контейнере нужно прописать следующую строку:

tmpfs /tmp tmpfs size=512m 0 0

И после этого сделать команду:

mount /tmp

Или перезапустить контейнер.

Все смонтируется ок:

cat /proc/mounts|grep 6617|grep '/tmp'
tmpfs /vz/root/6617/tmp tmpfs rw,relatime,size=524288k,nr_inodes=153600 0 0

А память в пределах tmpfs будет обсчитываться в контексте счетчика physpages контейнера и не требует дополнительных ограничителей.

В OpenVZ нигде /etc/fstab не обрабатывается, поэтому можно делать не боясь, что конфигурация будет сброшена:

grep -HiR 'fstab' /etc/vz/dists/*|wc -l
0

К сожалению, сам OpenVZ глобально управлять этим не умеет, а хотелось бы, поэтому прошу в баг трекер: https://bugzilla.openvz.org/show_bug.cgi?id=3040 и плюсуем таску :)

Как выполнить MySQL запрос внутри OpenVZ контейнера на Debian

mysql -udebian-sys-maint --socket /vz/root/7431/var/run/mysqld/mysqld.sock --password=`cat /vz/root/7431/etc/mysql/debian.cnf|grep password |tail -n 1|awk '{print $3}'` -e "show processlist"

Monday, 11 August 2014

Подсчитать объем сетевых tcp буферов используемых VPS на OpenVZ

cat /proc/user_beancounters |egrep 'tcp(snd|rcv)buf'| perl -e 'my$rcv=0; my $snd=0; for(<>){my @data=split/\s+/; if ($data[1] eq 'tcprcvbuf') { $rcv+=$data[2] } else { $snd+=$data[2]}}; $snd=int $snd/1024**2; $rcv=int $rcv/1024**2; print "snd buffers: $snd MB rcv buffer: $rcv MB\n"'

snd buffers: 538 MB rcv buffer: 306 MB

Monday, 4 August 2014

Использование suexec на CentOS 5 в собственных целях

Готовим окружение:

cd /var/www
mkdir /var/www/username
chown username:username /var/www/username
vim /var/www/username/suxx.sh

Кладем вот туда вот такой код:

#!/bin/bash
echo "suxx";
/usr/bin/id

Меняем права:

chown mamonov:mamonov /var/www/username/suxx.sh
chmod +x /var/www/username/suxx.sh

Входим под апачем:

cd /var/www/username
su apache -s /bin/bash
suexec username username suxx.sh

И получаем желаемое:

bash-3.2$ id
uid=48(apache) gid=48(apache) группы=48(apache)

bash-3.2$ suexec mamonov mamonov suxx.sh
suxx
uid=501(mamonov) gid=501(username) groups=501(username)

Рекомендую книгу: Сеть. Как устроен и как работает Интернет

Потрясающее произведение, которое открывает структуру сети Интернет с самого крупного масштаба. Здесь не будет описаний протоколов, тут не будет ничего про марки используемых оптических кабелей и ни слова настройке роутеров. Тут будет самое важное - описание того, что же на самом деле представляет собой Интернет.

Если для Вас сеть - нечто непонятно, работающее с помощью магии облако - эта книга для Вас. Вы сразу же поймете гениальную простоту архитектуры Интернета.

Это книга о людях и компаниях, которые создали Интернет. Тут объяснены причины успеха ИНтернета и причины его появления.

Если AMX-IX, DE-IX, Sprint, Cogent, Equnix, BGP - для Вас пустые слова, то эта книга для Вас.

Купить можно в Буквоеде (Спб) либо Озоне: http://www.ozon.ru/context/detail/id/26326082/ (на единственный идиотский отзыв призываю не обращать внимания).

А также Вы можете подписаться на Твиттер автора: https://twitter.com/ajblum

Saturday, 2 August 2014

Крутая книга по программирвоанию под Linux

http://www.amazon.com/The-Linux-Programming-Interface-Handbook/dp/1593272200/ref=sr_1_1?ie=UTF8&qid=1406980005&sr=8-1&keywords=linux+programming+interface

Tuesday, 29 July 2014

Сборка 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 секунд. Неплохо, вполне неплохо :)

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

Monday, 28 July 2014

Эффективность от использования 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. А также сжатия и криптографии!

Subscribe to: Posts ( Atom )

FastNetMon