Категория: Linux, Хостинг Автор: Hottab :: Среда 27 мая 2009 в 13:25

Довольно часто на одном VE сервере должны работать несколько нод, с разным приоритетом (в зависимости от выполняемых задач, тарифных планов и т.п.).

Было опробовано два метода разделения ресурсов.

Первый - жестко задавался CPULIMIT.

Этот метод выделяет ноде как бы виртуальный процессор (в процентах CPULIMIT от реального процессора), то есть нода работает, к примеру, на процессоре 200Mzh .

Второй - CPULIMIT устанавливается в ноль, то есть не ограничевается, но для каждой ноды прописывается ее “удельный вес“, параметр CPUUNITS. Объясню данный метод на примере.

Есть две ноды, одна с критичными задачами, другая - техническая, к примеру, для бэкапов. Первой ноде присваиваем CPUUNITS=200, второй CPUUNITS=100.

В результате получаем следующую ситуацию. При загрузке обоих нод на 100 процентов, первой ноде (CPUUNITS=200) будет выделено 66% процессорных ресурсов, а второй (CPUUNITS=100) - 33% .

Резюме:
Теперь о том что получилось на практике.

При балансировке первым методом каждой ноде выделялось определенное количество процессорных ресурсов, которых с трудом хватало на выполнение задач (apache, mysql). В результате высокий LA на самой ноде, ошибки TCP на VE, и более высокий LA, как следствие, на всем VE.

При использовании второго метода ресурсы CPU для каждой ноды не имеют жестких ограничений. Это значит что каждая нода может использовать процессор на максимальную мощность, в каждый момент времени (в соотвествии с “удельным весом“). Так как в реальности idle процессора достаточно большой, то это позволяет каждой ноде использовать весь объем процессорной мощности, и ограничения вступают в силу только в момент одновременной высокой нагрузке нескольких нод.

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


Категория: FreeBSD Автор: Hottab :: Воскресенье 24 мая 2009 в 1:02

Собственно сабж:
ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/


Категория: FreeBSD Автор: Hottab :: Воскресенье 24 мая 2009 в 0:52

Если в логах появляется такое :

kern.ipc.maxpipekva exceeded; see tuning(7)

можно потерять консоль на машину.

Моя ситуация - на клиенте был подключен NFS ресурс, один из файлов на этом ресурсе запускался через крон, достаточно часто. Затем NFS сервер был перенесен, но fstab на клиенте не был исправлен. В итоге каждый запуск скрипта по крону создавал процесс, который так и висел, не отваливаясь, а затем закончился буфер.

Резюме - внимательнее надо быть, на будущее ..
Ну и иметь ввиду что NFS коннекты так просто не умирают.


Категория: Личное Автор: Hottab :: Воскресенье 24 мая 2009 в 0:34

Новые фотки Насти, растем похоньку :)




Категория: FreeBSD Автор: Hottab :: Пятница 22 мая 2009 в 17:54

Полезности, переодически нужно бывает

Россия:

  • cvsup.ru.FreeBSD.org
  • cvsup2.ru.FreeBSD.org
  • cvsup3.ru.FreeBSD.org
  • cvsup4.ru.FreeBSD.org
  • cvsup5.ru.FreeBSD.org
  • cvsup6.ru.FreeBSD.org
  • cvsup7.ru.FreeBSD.org

Полный список здесь


Категория: FreeBSD Автор: Hottab :: Пятница 22 мая 2009 в 17:28

Проблема при сборке  apache 1.3.x на FreeBSD, начиная с 7 версии.
Проявляется следующим образом  - apache собирается, запускается, работает. Но при попытке собрать php как модуль -  apache  не стартует, ругается примерно таким образом:

Cannot load /usr/local/apache/libexec/libphp5.so into server: /usr/local/apache/libexec/libphp5.so: Undefined symbol “ap_user_id”

Причина в том,  что apache не знает о версии  FreeBSD 7.x.

Лечится все наложением патча из портов, следующим образом:

1. Идем в директорию с апачем
#cd /home/src/apache
2. Применяем патч
#cat /usr/ports/www/apache13/files/patch-ae | patch
3. Конфигурим и собираем apache


Категория: FreeBSD Автор: Hottab :: Воскресенье 17 мая 2009 в 22:33

Короткая инструкция, практически how-to.
Работает на FreeBSD, начиная с версии 5.3

При создании зеркала на работающей системе необходимо отключить защиту диска

# sysctl kern.geom.debugflags=16
kern.geom.debugflags: 0 -> 16

После ребута вернется нулевое значение.

Теперь, собственно, создаем Raid 1

# gmirror label -v -b round-robin gm0 /dev/ad0
Metadata value stored on /dev/ad0

Далее правим конфиг loader.conf

#echo geom_mirror_load=”YES” > /boot/loader.conf

Затем правим /etc/fstab , меняя /dev/ad0 на /dev/mirror/gm0

Проверям визуально fstab , все ли правильно, потом делаем reboot .
Если все сделано верно, система загрузится уже с зеркалируемого устройства (/dev/mirror/gm0).

Осталось сделать полноценное зеркало, то есть добавить второй винт

# gmirror insert gm0 /dev/ad2
GEOM_MIRROR: Device gm0: provider ad2 detected.
GEOM_MIRROR: Device gm0: rebuilding provider ad2.

Все, Raid 1 создан, винты в зеркале, осталось дождаться конца синхронизации

Полезное:
1. gmirror status gm0 - статус зеркала (можно смотреть статус процесса синхронизации )
2. gmirror list gm0 - более полная информация об устройствах в нашем Raid 1
3. gstat - статистика обращений к дискам


Copyright © 2009 Горячий [TAB].