Stable IT: August 2014

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

Subscribe to: Posts ( Atom )

FastNetMon