29 января 2014 в 19:22
Пытаюсь настроить LAMP (VPS Ubuntu 12.04, 512мб), но пока не получается.
При нескольких одновременных (конкурентных?) запросах, MYSQL падает и сам не поднимается.
Ложатся все сайты на сервере.
В друпале ошибка выглядит так:
Перед ней бывает еще такая ошибка
Чтобы сайты опять стали работать, помогает перезапуск MYSQL командой
, а в некоторых случаях перезагрузка всего сервера.
Типичная последовательность лога MySQL
/var/log/mysql/error.log:
140129 9:52:09 [Note] Plugin 'FEDERATED' is disabled.
140129 9:52:09 InnoDB: The InnoDB memory heap is disabled
140129 9:52:09 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140129 9:52:09 InnoDB: Compressed tables use zlib 1.2.3.4
140129 9:52:10 InnoDB: Initializing buffer pool, size = 64.0M
InnoDB: mmap(68681728 bytes) failed; errno 12
140129 9:52:10 InnoDB: Completed initialization of buffer pool
140129 9:52:10 InnoDB: Fatal error: cannot allocate memory for the buffer pool
140129 9:52:10 [ERROR] Plugin 'InnoDB' init function returned error.
140129 9:52:10 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140129 9:52:10 [ERROR] Unknown/unsupported storage engine: InnoDB
140129 9:52:10 [ERROR] Aborting
140129 9:52:10 [Note] /usr/sbin/mysqld: Shutdown complete
Сайт: http://hklib.com/
если вы видете ошибку вместо сайта, значит кто-то успел несколько раз нажать F5 раньше вас 
Стоит отметить, что если по сайту ходить медленно, то мускул не падает.
Если включить стандартное кеширование, то сайт положить сложнее (нужно долго держать F5 зажатой), но в конечном итоге все равно падает.
Вот htop в состоянии покоя, когда по сайту никто не ходит:
У меня вызывает вопросы количество процессов mysqld и их размер: от 18 до 25 штук, каждый весом от 11 до 13 мб.
Таким образом, даже в состоянии покоя, mysql жрет от 250 до 300 мб памяти (то есть больше половины памяти сервера).
Апач - от 11 до 15 процессов в состоянии покоя, каждый весом от 2-3 до 11-16 мб. (всего 200-250мб)
В процессах апача я заметил такие особенности: большинство процессов не запущены от какого-либо юзера; некоторые процессы запущены от рута, а во время активности на сайте иногда появляются процессы от юзера www-data.
После падения мускула, все его процессы умирают.
Хотелось-бы настроить апач чтобы он просто работал, чтобы можно было хотя-бы мелкие проекты перекинуть на этот сервер.
В гугле сижу уже два дня
Помню на патруле раньше была ошибка "too many connections to mysql" и тоже падал мускул и все сайты на сервере (если правильно помню), но потом они эту ошибку исправили. И почему-то мне кажется что это похожая ошибка (или просто кажется?)
UPD
что настраивал:
innodb_buffer_pool_size = 128М / 64М / 32M / 16М (кажется что на 32 сервер становится чутка более живучим, но все равно падает)
UPD
моя шпаргалка по настройке убунты на Digital Ocean:
https://docs.google.com/document/d/1CQplU7jDxyiNfHNU3ZSzK4C4cAcOjoHWluib...
планирую установить другую ось вместо убунты (но руки что-то долго не доходят), по другим мануалам, возможно после этого перестанет падать. Сейчас когда падает мускул - приходит письмо от метрики что сайты легли; захожу в админку океана и из админки ребутаю сервер. На убунте победить падения так и не смог
| Вложение | Размер |
|---|---|
 mysql_down.png | 13.19 КБ |
| htop_idle.png | 113.67 КБ |
Комментарии
- ага оушен
- выруби модуль locale - пробуй
- пробуй на nginx (http://www.drupal.ru/node/106587)
- /etc/mysql/my.cnf -
max_connections=500;
или
mysql> set global max_connections = 500;
почитай:
- http://artkiev.com/blog/error-plugin-innodb-init.htm
"в дистрибутиве mysql есть примеры конфигов my.cnf. есть конфиг my-small.cnf, как раз под такие мизерные объемы RAM. вот с ним, я думаю, у вас мускуль взлетит."
- https://forum.sysadmins.su/index.php?showtopic=40248955
выключил локаль.
Но ведь все равно у меня половина сайтов на русском - поэтому не везде смогу выключить. По ощущениям быстрее работать не стало.
Поигрался с настройкой innodb_buffer_pool_size = от 16 до 128 и при низких значениях (16-32), часто стало случаться так что сайт падает, а потом мускул перезапускается (точнее innodb):
Это уже в общем положительная подвижка, в логах появились такие записи:
140129 11:00:32 InnoDB: Completed initialization of buffer pool
140129 11:00:32 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 71593559
140129 11:00:32 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 71593569
140129 11:00:32 InnoDB: Waiting for the background threads to start
140129 11:00:33 InnoDB: 5.5.35 started; log sequence number 71593569
Если держать F5 зажатой секунду, то мускул падает и перезапускается, а если 2-3 секунды, то падает и уже не встает.
То есть как я понял вся проблема в этом: Fatal error: cannot allocate memory for the buffer pool и даже если я делаю самый маленький буфер (в 16мб) все равно апач и mysqld сжирают всю память и даже для этого маленького буфера не остается места.
Конечно, множно сказать "бери более мощный сервер", но ведь это не будет правильно, потому как все равно он упадет и будет падать, это вопрос времени.
Кроме того, у меня есть сайт с посещалкой до 14к в сутки, и с такими падениями даже пытаться этот сайт поднять на сервере думать не стоит.
Эти ссылки уже видел. Еще читал кажись оригинал на английском: http://omarusman.com/blog/tutorials/xampp-innodb-storage-engine-failed-w...
но меня эта инструкция очень напрягает, особенно по части "сделайте бэкап потому что после удаления файлов все может сломаться". Неужели вот прямо этими грязными костылями можно решить эту проблему? Честно говоря не верю, но когда окажусь припертым к стенке возможно попробую и это.
max_connections сейчас попробую
Команда mysql> show variables like "max_connections"; показывает что у меня уже стоит 500
попробовал поставить 100, но это не помогло
попробовал этот конфиг, но мускул даже не поднялся. Оно и не удивительно, ведь у меня убунта
140129 11:33:39 [Note] /usr/sbin/mysqld: Normal shutdown
140129 11:33:39 [Note] Event Scheduler: Purging the queue. 0 events
140129 11:33:39 InnoDB: Starting shutdown...
140129 11:33:40 InnoDB: Shutdown completed; log sequence number 71787872
140129 11:33:40 [Note] /usr/sbin/mysqld: Shutdown complete
Для убунты конфига такого не нашел, народ на стаке жалуется что его удалили из дистриба в последних версиях.
Вот еще парочка материалов:
http://stackoverflow.com/questions/10284532/amazon-ec2-mysql-aborting-st...
http://stackoverflow.com/questions/5376427/cant-connect-to-local-mysql-s...
но пока решения не найдено.
Что меня удивляет, так это нелепость ситуации. Я взял все стандартное: стандартная убунта, стандартный мускул и апач, ПХП. Обычный обновленный друпал. И при этом - фактически сайт работать не может. Как такое может быть? Вроде как даже есть инструкция по установке друпала на оушен, но там никаких подводных камней не описано, просто самый минимум, который мне итак понятен: https://www.digitalocean.com/community/articles/how-to-install-drupal-on...
Как варианты рассматриваю поменять версию мускула, апача, или ось.
UPD
Кстати, нашел очень любопытную статью про оптимизацию апача: http://www.linuxjournal.su/?p=1607
буду читать и параллельно изучать теорию.
И еще я вот не понимаю, в этих падениях виноват апач или таки MySQL? Может кто-нибудь однозначно сказать?
мне кажется 512 мб маловато будет для 14 к.
ща получше стало, через f5 пробивается, без f5 ссылки норм работают.
ну на таком маленьком инстансе с 512 и одним ядром я даже не собирался запускать сайт с 14к.
Если у меня получится настроить чтобы не падало, то думаю более комфортно для работы посещаемого сайта хотя-бы два ядра, а это тариф за 20 баксов/месяц. Сейчас тот сайт работает у знакомого на хетцнере.
У меня задача минимум мигрировать с Джино, где я держу десять мелких, почти не посещаемых проектов.
да, получше, но праздновать победу еще рано. Единственное что сделал существенного, это уменьшил innodb_buffer_pool_size до 16M
По идее если думать дальше, то нужно как-то ограничить апач и мускул в памяти. Уменьшить очереди запросов (или как это правильно называется) к тому и к другому. Для того чтобы не возникало ситуации когда для мускула совсем не остается памяти чтобы создать buffer pool
Ок, продолжаю свои поиски. Стал читать про то как ограничить апач в памяти (или в количестве процессов), поставил в /etc/apache2/apache2.conf MaxClients 30 (вместо 150 дефолтных), никакого заметного эффекта это не дало.
Далее в /etc/mysql/my.cnf установил max_connections = 10 (вместо 500 дефолтных). Ошибка изменилась на такую:
частенько видел ее на патруле
Если F5 держать долго - то сначала "too many connections", потом "can't connect to socket" и умирает.
Если держать пару секунд - то после ошибки о превышении числа коннектов сайт опять работает.
Следующая настройка которую попробовал: max_user_connections = 10 (можно поставить и больше). С такой настройкой завалить сайт нажатием F5 уже не получается. Вываливается ошибка, а после обновления страницы сайт опять работает.
Ошибка такая:
Правда я не уверен, поможет-ли установка лимита max_user_connections на реальной нагрузке, или только от зажатой F5, когда все запросы создает один юзер.
для начала поставь mysql tuner и посмотри что он скажет, но 512 видимо мало
интересно, что аудит покажет - http://www.drupal.ru/node/106914
max_connections=500; - на vps с 512мб ОЗУ, Вы серьёзно?
Автор, вы смотрите не те логи. Посмотрите "/var/log/syslog", вероятнее всего там будет написанно, что работа сервера MySQL завершена из-за нехватки ОЗУ.
1) Если Вы используете apache2, включите такие модули как expires, headres, deflate. Уменьшите значение keep_alive.
2) Используйте mod_php5 совместно с одним из акселераторов xcache, apc, eaccelerator. Это порядком сократит потребление памяти.
3) Дайте угудаю, php memory_limit 256mb? Посчитайте сколько запросов Ваш сервер сможет обработать при самом плохом раскладе (потребление 256мб на один поток/процесс)?
4) https://github.com/subsven/mysql-5.5-debian/blob/master/support-files/my... - не работает у Вас не по причине того что Ubuntu отличаеться от Debian. (тут тоже нужно думать, а не просто копировать)
5)
- ещё раз внимательно прислушайтесь, человек дело говорит. Примеры конфигов можно найти на своём vps примерно тут/usr/share/doc/mysql-server-5.5/examplesСпрашивайте, если есть вопросы
может на статью насобираем 
chilic, спасибо за такие ценные советы и указания!
Нашел. К сожалению (или к счастью) после вчерашних настроек мускул перестал падать, даже если долго держать зажатой F5 залогинившись на сайте.
типичный кусок лога:
Jan 30 07:15:36 localhost kernel: [165391.100713] select 21786 (apache2), adj 0, size 4084, to kill
Jan 30 07:15:36 localhost kernel: [165391.100714] select 21845 (apache2), adj 0, size 4454, to kill
Jan 30 07:15:36 localhost kernel: [165391.100715] select 21972 (apache2), adj 0, size 4586, to kill
Jan 30 07:15:36 localhost kernel: [165391.100729] select 1 (init), adj 0, size 365, to kill
Jan 30 07:15:36 localhost kernel: [165391.100732] select 817 (php5-fpm), adj 0, size 825, to kill
повторяется очень, очень много раз. Видимо это отдельные обращения к базе данных, которых друпал делает немало. За несколько секунд зажатой F5 образуется 7 мб логов
Вчерашний лог (в котором записана последовательность падения мускула) к сожалению весит 650 мегабайт, и быстро открыть его не получилось. Начал разбираться с утилитой logrotate. Однако буду иметь ввиду в какой лог лезть при следующем падении.
Честно - не знаю какое там сейчас значение, возможно 128. Но на самом деле это не очень важно, потому что ПХП (друпал) никогда не съедает на загрузку страницы прямо все 128 мегабайт, а обычно намного меньше. Не настроенный сайт с кучей views и кучей лишней разметки (если смотреть на цифры которые показывает девел) - требует 50 мб на загрузку например главной страницы. Мои сайты обычно меньше - бестмапс например кушает 30 мб (это если залогиненный), но для анонимов я подозреваю друпал использует меньше, а уж тем более для закешированных страниц.
Память в основном нужна (насколько я помню) в основном для GD (создание эскизов, ватермарки), и чем больше фотки мы хотим обрабатывать с помощью GD, тем больше нужно памяти ПХП. Возможно есть еще какие-то операции типа крона или еще чего где нужно много памяти. Но ведь не на каждый запрос страницы.
спасибо, это я сделаю
Тоже буду пробовать.
интересно, буду думать. У меня опыт работы в консольном линуксе не большой, всего три дня, поэтому всего сразу мне не понять.
спасибо, здесь действительно они есть. В гугле искал куда эти конфиги делись - не нашел.
Статья это прекрасно, но пока мне хватает всяких вариантов которые можно пробовать. Для меня даже важнее не столько скорость, сколько стабильность. Хотя скорость конечно тоже очень важна.
Итого, с текущей конфигурацией получается что сайт с включенным БД кешем держит 20 запросов в секунду, более 20 запросов появляются таймауты и увеличивается время ответа (фактически это означает что при 25-30 запросов/сек - сайт перестанет вообще работать), но и это для начала неплохо!
Всем спасибо за советы, увидел несколько новых направлений куда можно дальше копать
Судя по логам, Вы используте php-fpm. В этом случае лучше отказаться от Apache и перейти на Nginx.
Вы будете приятно удивлены, если настроите кэш на Nginx или Varnish или Squid.
Это даст гараетию того что сервер не умрёт от 20 запросов в секунду. Однвко это только для анонимных пользователей.
Ну и надеюсь Вам уже понятно что Memcache Вам не поможет (512мб).
Чилик - умный. Чилик нам поможет.
спасибо за советы! Вещей за которые можно хвататься много, поэтому я немного теряюсь, ведь моя первоначальная цель - настроить самую простую конфигурацию и заставить ее просто работать. Через два дня кончается Джино, принципиально не хочу им платить и съехать на свой сервер. Nginx меня пугает более сложной настройкой. Да, я понимаю что он быстрее и ест меньше памяти, но сейчас время поджимает. Varnich, акселераторы, это все классно, но ведь опасно делать это бездумно. Лучше делать маленькие шаги, но осознавать что ты делаешь чем попытаться настроить все и сразу и погрязнуть в системе которую ты не можешь контролировать, или чего хуже - потерять данные работающих сайтов.
Ставил PHP по этой инструкции, почему там php-fpm поставилось, не знаю, наверное по дефолту.
Поэтому моя позиция достаточно консервативная - настроить апач для начала. Да, я понимаю что опытные люди скажут "фу, апач это не круто", и будут правы. Но и я буду прав когда скажу что хочу понять как работает самая простая конфигурация.
в логе кроме бесконечных селектов нашел такой кусок:
var/log/syslog
Jan 30 08:23:29 localhost /etc/mysql/debian-start[24561]: Upgrading MySQL tables if necessary.
Jan 30 08:23:30 localhost /etc/mysql/debian-start[24564]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Jan 30 08:23:30 localhost /etc/mysql/debian-start[24564]: Looking for 'mysql' as: /usr/bin/mysql
Jan 30 08:23:30 localhost /etc/mysql/debian-start[24564]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Jan 30 08:23:30 localhost /etc/mysql/debian-start[24564]: This installation of MySQL is already upgraded to 5.5.35, use --force if you still need to run mysql_upgrade
Jan 30 08:23:30 localhost /etc/mysql/debian-start[24575]: Checking for insecure root accounts.
Jan 30 08:23:30 localhost /etc/mysql/debian-start[24580]: Triggering myisam-recover for all MyISAM tables
Не знаю, говорит-ли он вам что-нибудь и можно-ли из этого сделать какие-либо выводы.
По поводу 512мб. Для меня это не какой-то жесткий лимит. Тарифов много, и вариант перехода на тариф с 1 гигом вполне вероятен. Но мне кажется наивно решать проблему производительности увеличением железа. Если на таком сервере не смогу настроить - то на более крупном оно тоже не будет работать. Я лишь отодвину проблему чутка, но ведь не решу ее. Моя задача - понять как работает сервер (научиться), а это можно сделать на любой конфигурации.
Удачи Вам. Будут вопросы пишите.
А лучше пишите здесь о своих достижениях.
Апач + FPM точно не круто.
спасибо!
да, наверное не круто, но это дефолтно для океана.
Внимательно сравнил мой конфиг с my-small.cnf
Подправил кое-какие значения и добавил блок:
key_buffer_size = 16K
net_buffer_length = 2K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
sort_buffer_size = 64K
table_open_cache = 4
thread_stack = 128K
Отличия моего конфига от my-small.cnf:
Вот эта строка в my-small была закомменчена
но если ее закомментить, то мускул начинает падать, поэтому раскомментил (видимо дефолт там сильно больше чем 16М)
У меня есть две такие строки:
max_user_connections = 10
в my-small их вообще нет
Итого, друпал 7 с БД кешем на полученной конфигурации выдерживает до 30 запросов/сек.
Но самое приятное - мускул перестал падать, и это уже маленькая победа.
Пошел переносить сайты с джино.
в общем, как я понял, проблема была в MySQL, а не в апаче и не в ПХП.
При зажатой клавише F5 (что соответствует 15 запросам/сек), память теперь заполнена лишь на половину, процессор чуть больше половины.
Потом когда будет время продолжу тюнить сервер
напоследок вопрос: включение SWAP файла считается дурным тоном?
встречал не мало упоминаний когда люди уверенно говорили что нужно включить SWAP файл. Может они имели ввиду для сервера с 512мб? Я все равно настраиваюсь взять 1гиг оперативки когда буду увереннее и буду понимать зачем мне это надо, но вопрос все равно есть - в каких случаях его обычно используют?
https://www.digitalocean.com/community/articles/how-to-add-swap-on-ubunt...
Жесть, ты бы сразу написал что у тебя DO... Мозги парил )))
Я сразу там свап врубаю.
камрады, нужна помощь
После решения проблемы прошло чуть больше недели.
Внезапно мускул лег окончательно и не поднимается даже после перезагрузки сервера.
К сожалению я не могу вспомнить что делал в тот день, и делал-ли вообще (скорее всего ничего не делал, хотя знаю что само не должно падать).
на команду service mysql restart отвечает
start: Job failed to start
На команду sudo /etc/init.d/mysql restart отвечает
utility, e.g. service mysql restart
!>
Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) and then start(8) utilities,
e.g. stop mysql ; start mysql. The restart(8) utility is also available.
start: Job failed to start
логи, здесь ошибка похожая что и была раньше
/var/log/mysql/error.log
140215 13:10:48 [Note] Plugin 'FEDERATED' is disabled.
140215 13:10:48 InnoDB: The InnoDB memory heap is disabled
140215 13:10:48 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140215 13:10:48 InnoDB: Compressed tables use zlib 1.2.3.4
140215 13:10:48 InnoDB: Initializing buffer pool, size = 16.0M
140215 13:10:48 InnoDB: Completed initialization of buffer pool
InnoDB: Error: checksum mismatch in data file ./ibdata1
140215 13:10:48 InnoDB: Could not open or create data files.
140215 13:10:48 InnoDB: If you tried to add new data files, and it failed here,
140215 13:10:48 InnoDB: you should now edit innodb_data_file_path in my.cnf back
140215 13:10:48 InnoDB: to what it was, and remove the new ibdata files InnoDB created
140215 13:10:48 InnoDB: in this failed attempt. InnoDB only wrote those files full of
140215 13:10:48 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
140215 13:10:48 InnoDB: remove old data files which contain your precious data!
140215 13:10:48 [ERROR] Plugin 'InnoDB' init function returned error.
140215 13:10:48 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140215 13:10:48 [ERROR] Unknown/unsupported storage engine: InnoDB
140215 13:10:48 [ERROR] Aborting
140215 13:10:48 [Note] /usr/sbin/mysqld: Shutdown complete
в системном логе какие-то невероятные тонны ошибок, которые понять я просто не в состоянии
/var/log/syslog
http://pastebin.com/raw.php?i=4q68byKT
Перебор параметров в my.cnf ничего не дал.
В гугле не могу найти ничего, что помогло-бы поднять мускул
Может-ли это быть аппаратная ошибка?
Может-ли возникновение такого бага как-то зависеть от дата-центра? Может AMS-2 имеет какие-то нехорошие ошибки? (кстати создание дроплетов на AMS1 уже закрыто)
Поможет-ли например смена версии MYSQL на более новую (апгрейд) или на более старую?
Может-ли на эту ошибку влиять сама ОСь? Может есть смысл мигрировать на более новую убунту 13, или вообще на другой дистриб, например CentOS?
Может поможет: http://www.debian-tutorials.com/how-to-fix-error-unknownunsupported-stor...
Посмотри, может у тебя swap не включен, создать то ты его создал, а сделал чтобы он подключался?
файлы удаляются, но совсем скоро опять появляются, причем похоже с таким-же размером.
Помогает-ли удаление этих файлов или нет, сказать не могу, так как перед этим добавил в my.cnf строку
и это решило проблему. После перезагрузки сервера мускул поднялся.
в следующий раз если вдруг мускул упадет, попробую в первую очередь удалить эти файлы.
я его кажется даже не создавал.
и вообще я не уверен что свап имеет хоть какое-то отношение к падению мускула и InnoDB в частности. Ведь если мускулу может не хватить оперативки, точно так-же ему может не хватить и свапа. Но проблема в том, что он не должен падать сколько-бы у него памяти не было. Поэтому я считаю что увеличение памяти лишь отодвинет его падение, но не предотвратит
Ведь писал ранее вопрос:
но ведь на этот вопрос мне никто не ответил, поэтому я ничего и не стал делать с этим файлом. Прежде всего я даже не понимаю зачем он нужен и в каких случаях используется на веб-серверах в таких условиях включать его просто потому что "кто-то его использует" считаю недостаточным обоснованием. Где про него можно почитать, статью может кинешь?
И еще одна особенность оушена.
бэкапы там создаются и хранятся только за последние три дня.
Мускул у меня упал где-то пять дней назад, а в метрике было отключено оповещение о падениях (на шаред хостингах у меня никогда не падало, поэтому нет привычки постоянно мониторить сайты).
То есть в бэкапах даже не было снимка сервера ДО этого фатального падения. Погрустил немного. Правильно говорят на бэкапы надейся а сам не плошай.
И еще. Сегодня во время попытки оживить сервер возникла очень неприятная и щекотливая ситуация. В консоли вбил reboot, машина просто ушла в даун, то есть перестала работать вообще. Напрягся. Перезагрузил из контрольной панели ДО - заработало. Но осадочек остался - что это? Такое бывает? Это нормально?
Видимо придется придумывать что-то как бэкапить проекты куда-то в другое место.
у меня не так, делаются каждый 3 день, а хранятся у меня допустим уже 6 бэкапов с 26.01. (полагаю когда зарегался)
а снимок, это другое, ты сам делаешь.
+тех поддержка адекватная, быстрая.
это обязательно, не ложи яйца в одну корзину.
Включи свап, дело 3х минут, и попробуй.. Подумай, у тебя памяти то всего 512 там, система + пхп у бд, как эт все влезет? Пусть будет, на то там и ssd стоит чтобы быстро работало..
У меня была та же проблема. Я поменял план на 1 гиг и проблема ушла даже без извращений с конфигами.
В общем проблема все так-же постоянно повторяется и уже порядком задрала.
включение опции
дает меньше шансов, что мускул упадет окончательно, но он все равно падает. Падает, поднимается, опять падает.
В итоге оно не сильно-то и помогает. Еще момент - включение этой опции не позволяет сделать например импорт базы данных в май-админе. То есть мне нужно сначала закомментить строку, перезапустить mysql, залить базу, раскомментить строку, перезапустить. И так для каждой вновь импортируемой базы. Согласитесь, не очень удобно.
Таким образом, на данный момент я склоняюсь к тому чтобы переустановить сервер на какой-нибудь другой операционке, и (возможно) с другой версией MySQL, отличной от той, которая у меня работает сейчас.
Как вариант, подумываю о том чтобы сменить версию мускула на текущем сервере, но не уверен что это даст положительный результат.
А что за сервер? Хетцнер какой-нить?
Digital Ocean тариф 5 баксов/месяц 512мб памяти
Хочу поставить центось, но что-то время трудно найти.
на убунте пока не получается
хотелось-бы в это верить, но... коммерсант, сидящий внутри меня негодуэ.
дело в том что ресурсы, хоторые я хощу на океане не покроют затрат в 20 баксов (а еще учтем что бакс дорожает).
кроме того, на все эти ресурсы идет весьма и весьма маленькая посещалка (суммарно может 300 чел/сутки), чего явно недостаточно для выделения каких-либо дополнительных ресурсов. Всего там наберется от силы пять сайтов, из которых имеют хоть какую-то посещалку всего два. Если триста человек разделить на 24 часа, умноженных на 60 минут, то станет понятно что при такой посещалке большую часть времени сервер просто простаивает без нагрузки и ничего (вообще) не делает.
Появилась идея воспользоваться One Click Install с предустановленным друпалом:
Надеюсь там учтены какие-то настройки нужные для друпала и мускул не будет падать?
Если так, то останется только настроить мультисайтовость, чтобы можно было хостить много сайтов а не инстанс в одно лицо как это у них сделано по дефолту
Сомневаюсь, что там кто-то что-то учитывал. Просто скрипт установки дистрибутива.
я запостил на ихний форум вопрос, один ответил что мне нужно включить своп, как выше и писал UnnamedNETUA: https://www.digitalocean.com/community/questions/drupal-mysql-dies-and-n...
я раньше этот мануал смотрел но не сделал сразу т.к. он мне казался большим и сложным. Но теперь походу придется сделать: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubun...
да, мануал в общем не сложный. Единственный косяк который я допустил - вбил неправильный размер файла подкачки. По дефолту в мануале этом 256мб, а я хотел не меньше гига (поставил два) - места на диске полно поэтому не жалко. Из-за этого потом пришлось искать еще один мануал "как увеличить своп". Прошло 5 дней, пока ни разу не упало (тьфу-тьфу-тьфу)
Интересно, Вы вообще понимаете, что лучше чтобы своп не использовался вообще?
я понимаю. и я пытался это сделать неоднократно. не вышло. если на сервере всего 512 мегабайт памяти, я не вижу других способов как обойтись без него.
ну скажем, эта бесполезная штука остановила непредвиденные падения сервера. причем время от времени падает так, что ребут не помогает. сервер валяется перманентно.
самое главное в сервере - надежность. со свопом он работает стабильнее (пока), на скорости на глаз я различий не вижу (замеров не делал).
предложение взять вместо 512 1gb неприемлемо, т.к. проекты которые я хощу на этом сервере не приносят денег и тратить на них больше - глупо.
и кстати, nginx ваш не поможет, потому что основную часть памяти сжирают именно процессы mysql.
толку от того что мы освободим несколько десятков мегабайт нет, потому что когда на сервер зайдет чуть больше народу чем в среднем - он все равно упадет. Так-же перманентно и необратимо как с апачем
и напоследок. ничего, что совет включить своп дал мне сам сотрудних техподдержки DO?
вы считаете что он ошибся? https://www.digitalocean.com/community/users/ryanpq
я считаю что сервер не должен падать независимо от того стоит там апач или nginx. вопрос только в правильной настройке, которую сделать могут увы не все
скажите, а у вас есть phpmyadmin?
можете написать сюда "Версия клиента базы данных"?
Либо http://php.net/manual/ru/mysqli.get-client-info.php
/* Для определения версии клиентской библиотеки MySQL
нет необходимости в создании соединения */
printf("Версия клиентской библиотеки: %s\n", mysqli_get_client_info());
?>
Если там не
то, возможно, вам это поможет. Я сам всегда этим пользовался, но не знал почему так. А теперь один умный человек объяснил мне, почему должно быть так.
Кстати это всех касается у кого не 50011)
Дело в том, что недавно обновлял свой сервер gentoo. Встал mysql сервер 5.5, а версия клиента осталась прежней - "mysqlnd 5.0.11-dev - 20120503" если быть точным.
при этом был выключенный флаг для сборки USE=libmysqlclient. При этом было указано, что этот флаг не рекомендуется включать (использовать).
дома и на работе у меня стоит debian jessie - там версия клиента соответствует версии сервера. меня удивило, почему не обновилось и решил узнать. на русском форуме ничего толком не ответили - я спросил на английском и там мне очень подробно ответили. в конце ссылка.
Для тех, кто не хочет читать на английском:
Дело в том, что пакет mysql предоставляет библиотеку клиента libmysqlclient, написанную на C. Но PHP не C! По умолчанию она используется пакетом php для взаимодействия с сервером mysql при использовании любого апи (mysql, mysqli, PDO). При этом все, что передается на сервер по протоколу TCP по умолчанию на 3306 порт, сначала
конвертируется с PHP в Си, потом обратно из Си в PHP.
PHP Group решила что так работать недостаточно эффективно и начиная с PHP 5.2 выпустила альтернативную библиотеку клиента mysql.
Эта новая библиотека получила название mysqlnd - mysql Native Driver.
Она была новой и экспериментальной, но давала хороший прирост производительности даже с версией PHP 5.2
В дистрибутиве debian этот пакет включается
В настоящее время пакет mysql поддерживается группой Oracle, в то время как разработка пакета mysqlnd была начата в Sun. Исходный код этой библиотеки был слит в upstream пакета php начиная с версии 5.3
С этих самых пор ответственность за поддержку этого пакета взяли на себя PHP Group.
В дистрибутиве gentoo этот пакет ставится по умолчанию, начиная с версии PHP 5.4
После этого объяснения я почувствовал гордость за gentoo)
Извините за вольный перевод, оригинал здесь - https://forums.gentoo.org/viewtopic-t-1001646.html
Очень странно, что на русском языке я эту информацию не встречал.
Я сам на выходных ставил эксперимент и собирал с libmysqlclient. Работало хуже. при обычной нагрузке 0.43, 0.55, 0.66, с включенным пакетом было больше как ни странно в разы, апач висел, mysql уставал. Правда я еще mysql_upgrade выполнил после первого падения , а не сразу после обновления.
Теперь все работает как часы, сейчас сервер перегрузил после обновления, до этого был аптайм больше полгода)
Вот только почему PHP Group не выпустило новую библиотеку с 2012 года и во всех дистрибутивах версия одна и та же меня смутило, но спрашивать я постеснялся - возможно там с лицензиями оракла что-то связано на код. Но если на вашем хостинге она не включена, возможно, вы теряете в производительности и немало.
а вообще на русском подробно здесь написано - http://php.net/manual/ru/mysqlnd.overview.php
Наркоманией отдаёт.
Пых написан на Си.
Пых работает с расширениями на пыхе и на си.
А вообще, все либы идут в .so
Версия клиента может приводить к косякам, но причины, думаю, более прозаические чем описанные выше.
Да не за что. Я верю в карму, со мной очень хорошо поступили, когда это объяснили как новичку на форуме) Если это кому-то поможет, значит вернется - я буду очень рад.
Я не буду спорить, возможно перевел не совсем корректно, поэтому и дал ссылку.
Видимо, речь шла об этом абзаце
libmysqlclient не является расширением PHP, а лишь внешняя библиотека, которая подключается на этапе компиляции, и оптимизирована она для работы на Си.
А mysqlnd - является и оптимизирована специально для PHP.
Поэтому ваш комментарий не очень понял.
Так а какой результат то? Можете итоги подвести? Помогло ли что-то, и если да, то что?