Восстановление сбойного загрузочного диска в Linux RAID 1
Наткнулся на хорошую статью по замене загрузочного диска в софтверном RAID Linux.
Если кратко, то на второй уцелевший диск надо засетапать grub )
Наткнулся на хорошую статью по замене загрузочного диска в софтверном RAID Linux.
Если кратко, то на второй уцелевший диск надо засетапать grub )
Наверно многим известна проблема, когда с pure-ftpd при обрыве соединения невозможно сделать докачку файла.
По этому поводу было много разговоров в mailing list, но чето дела не нашел.
На суд общественности предлагаю патч: http://www.pentarh.com/files/patch-correct-resume.txt
Патч добавляет опцию -7 к демону pure-ftpd, благодаря которой демон пишет контент передаваемого файла ПРЯМО в файл назначения, а не во временный файл типа “.pureftpd-upload.XXX.YYY.ZZZ”. Так же он сохраняет обработку команды APPE.
Соответственно, в конфиге добавилась аналогичная опция:
NoAtomicFile yes
Благодаря этому становится возможным докачка файла после обрыва связи.
Интрукции при сборке из исходников:
1. Положить патч в корневой каталог исходников pure-ftpd 1.0.22
2. patch -p0 < patch-correct-resume.txt
3. ./configure и все такое
Инструкции FreeBSD:
1. Положить файл в /usr/ports/ftp/pure-ftpd/files/
2. make config, make install
В основном это касается Virtual Dedicated Server (VDS/VPS), т.к. дефолтная установка MySQL на CeontOS/Fedora/RHEL с дефолтным my.cnf делает malloc на сотню с лишним мегабайт.
Конечно на потребляемую память MySQL влияют такие параметры как key_buffer, query_cache_size и т.п. Но они по дефолту идут минимальные, а кеш запросов вообще по моему отключен по дефолту.
Так вот все очень просто. Добавляем в my.cnf:
skip-innodb
skip-bdb
Это выключит хандлеры InnoDB и BerkeleyDB и всю потребляемую ими память. Ну конечно делать это нужно если вы не используете вышеприведенные типы таблиц.
Далее рестартуем мускуль и видим в топе что он занимает десяток-другой мегабайт.
PS: в большинстве случаев не помешает опция и skip-networking. А вот thread_cache_size я советую поставить в значение 5-15 (в зависимости от нагрузки)
Дефолтные установки Data Sources для cacti не подходят для точного определения месячного 95% percentile для любого девайса.
Убедиться в этом можно, заглянув в инфо любого RRD файла со статистикой интерфейсов:
#rrdtool info interface-traffic.rrd
Там мы можем наблюдать следующие вещи. Посмотрим на первый (самый точный) Round Robin архив:
rra[0].cf = “AVERAGE”
rra[0].rows = 600
rra[0].cur_row = 335
rra[0].pdp_per_row = 1
Бывает такая фигня с yum‘ом на VPSках с памятью <=256M, когда пытаешься сделать какое то телодвижение с yum‘ом, он вываливается с таким бектрасом:
-bash-3.2# yum search foobar
Loading “fastestmirror” plugin
Loading mirror speeds from cached hostfile
* epel: ftp.nluug.nl
Traceback (most recent call last):
File “/usr/bin/yum”, line 29, in ?
yummain.main(sys.argv[1:])
File “/usr/share/yum-cli/yummain.py”, line 105, in main
result, resultmsgs = base.doCommands()
File “/usr/share/yum-cli/cli.py”, line 293, in doCommands
return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds)
File “/usr/share/yum-cli/yumcommands.py”, line 383, in doCommand
return base.search(extcmds)
File “/usr/share/yum-cli/cli.py”, line 867, in search
for (po, matched_value) in matching:
File “/usr/lib/python2.4/site-packages/yum/__init__.py”, line 1313, in searchGenerator
for sack in self.pkgSack.sacks.values():
File “/usr/lib/python2.4/site-packages/yum/__init__.py”, line 537, in <lambda>
pkgSack = property(fget=lambda self: self._getSacks(),
File “/usr/lib/python2.4/site-packages/yum/__init__.py”, line 392, in _getSacks
self.repos.populateSack(which=repos)
File “/usr/lib/python2.4/site-packages/yum/repos.py”, line 214, in populateSack
self.doSetup()
File “/usr/lib/python2.4/site-packages/yum/repos.py”, line 66, in doSetup
self.ayum.plugins.run(’postreposetup’)
File “/usr/lib/python2.4/site-packages/yum/plugins.py”, line 169, in run
func(conduitcls(self, self.base, conf, **kwargs))
File “/usr/lib/yum-plugins/fastestmirror.py”, line 90, in postreposetup_hook
repomirrors[str(repo)] = FastestMirror(repo.urls).get_mirrorlist()
File “/usr/lib/yum-plugins/fastestmirror.py”, line 142, in get_mirrorlist
self._poll_mirrors()
File “/usr/lib/yum-plugins/fastestmirror.py”, line 155, in _poll_mirrors
pollThread.start()
File “/usr/lib/python2.4/threading.py”, line 416, in start
_start_new_thread(self.__bootstrap, ())
thread.error: can’t start new thread
Это означает что у него есть плагин “fastestmirror“, который жрет много памяти в пике. Ессесно ее не получает, т.к. память лимитирована.
Лечится добавлением –noplugins к команде yum‘а или добавлением памяти на VDS.
Поскольку в VPS память лимитирована, а директадмин ставится с размахом, то нужно поубавить его аппетиты. Ну не столько его, сколько приложений.
1. Редактируем /usr/local/directadmin/conf/directadmin.conf:
numservers=2
2. Редактируем /etc/dovecot.conf:
protocols = imap pop3
(можно вообще pop3 оставить)
login_processes_count= (здесь от 2 до 5)
3. /etc/httpd/conf/extra/httpd-mpm.conf
Ну здесь надо расчитать по памяти конечно. Значения могут быть и больше.
# prefork MPM
StartServers 2
MinSpareServers 2
MaxSpareServers 5
ServerLimit 32
MaxClients 32
Можно подумать на счет целесообразности KeepAlive.
Ну и затем рестартануть VPS.
При создании темплейта CentOS x86_64 обнаружил проблему.
При выполнении команды
# vzpkgcache -f centos-5-x86_64-minimal
Начинают валиться ошибки типа:
sed: can’t read /etc/syslog.conf: No such file or directory
ERROR: Script install-post failed
После чего скрипт отваливается. Порывшись, нашел небольшой work-around. Однако и там допущена неточность.
Патчить ничего не нужно. Необходимо лишь правильно подредактировать файл “/vz/template/centos/5/x86_64/config/minimal.list“:
Теперь все должно сработать
Работает? Не трогай!