LINUX.ORG.RU

Миграция Debian-сервера на другое железо

 , , , ,


0

1

Есть сервер, основанный на обычном десктопном железе: Core i5 4x2.5Ghz, 16GB RAM, 60GB SSD + 1TB HDD на базе Debian 8.1 (64bit). Установлен стандартный набор для веб сервера: nginx + php-fpm + mysql + composer и так далее. Вся система кроме /var находится на ssd, /var на жестком диске. (P.S я бы вообще, тому, кто это ставил и настраивал, уши бы пооткрутил ;-))

Веб приложение на всём этом работает нормально, не то, чтобы летает, но выполняет поставленные задачи на ура - только стоит в офисе. Начальство поставило задачу перенести приложение на внешний сервер.

Есть внешний сервер: Xeon 8x3.6 Ghz, 32GB RAM , 2x480GB SSD + 2x1TB HDD

Из двух SSD был собран RAID1 на базе встроенного контроллера Intel. Был создан образ сервера с исходного железа с помощью Clonezilla, развёрнут на виртуальной машине Virtualbox, выполнено обновление Debian до 8.5 и установлен dmraid. Затем снова создан образ с помощью Clonezilla и всё это успешно было перелито на удалённый сервер и развёрнуто, всё определилось, всё работает.

Затем в нерабочее время перенесли дамп актуальной mysql базы и перевели пользователей на новый сервер. Люди начали заходить и тут...началось...

Все восемь ядер по 3.6 были загружены процессом mysql, приложение жутко тормозит, работать невозможно. При номинальной загрузке в 40 активных сеансов, новый сервер просто не мог обрабатывать запросы. Старый всё это обрабатывает без особого напряжения. Пришлось экстренно возвращать пользователей на прежний сервер и разбираться, почему так произошло.

После разбора полетов был залит оригинальный образ Debian 8.1 на SSD без RAID массива и, даже не выводя в продакшн видно, что приложение работает быстрее и нагрузочные тесты проходят, 50 одновременных пользовательских сеансов обрабатываются без проблем.

Вопрос: Что могло привести к такому поведению системы? Обновление? RAID массив? Особенности разметки диска?

Да, сервер будет работать на Debian 8.1, я настрою iptables, закрою все лишние порты, но всё равно переживаю, так ка недавно вышел 8.6 и там закрыли очередную пачку уязвимостей...как тогда обновиться...?

Индексы в базе не потерялись при переносе?

slowpony ★★★ ()
Ответ на: комментарий от slowpony

В 5.6.8 query_cache_type off по-умолчанию, например, это может повлиять на производительность (даже если ты не трогал конфиг, а только обновился)

slowpony ★★★ ()
Ответ на: комментарий от slowpony

Mysql

Исходный сервер 5.5.44-0+deb8u1 Обновленный сервер 55.52-0+deb8u1

Версию mysql сервера откатывал назад, специально нашел старые пакеты и переустановил - ничего не изменилось

Goldsman ()
Ответ на: Mysql от Goldsman

База переносилась стандартными средствами mysqldump для экспорта и mysql для импорта, объем базы ~10Gb, в виде .sql файла 2Gb

Goldsman ()

Не используй fake-raid. Делай массив на mdadm.

Deleted ()
Ответ на: комментарий от goingUp

большие большие SELECTы с созданием временных таблиц. Вот что пишет mysqltuner

MySQLTuner 1.3.0 - Major Hayden <major@mhtx.net>

>> Bug reports, feature requests, and downloads at http://mysqltuner.com/ >> Run with '--help' for additional options and output filtering [OK] Logged in using credentials from debian maintenance account. [OK] Currently running supported MySQL version 5.5.44-0+deb8u1 [OK] Operating on 64-bit architecture

-------- Storage Engine Statistics ------------------------------------------- [--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM [--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17) [--] Data in InnoDB tables: 10G (Tables: 108) [!!] Total fragmented tables: 108

-------- Security Recommendations ------------------------------------------- [OK] All database users have passwords assigned

-------- Performance Metrics ------------------------------------------------- [--] Up for: 24m 6s (62K q [43.130 qps], 484 conn, TX: 38M, RX: 13M) [--] Reads / Writes: 99% / 1% [--] Total buffers: 3.1G global + 2.7M per thread (151 max threads) [OK] Maximum possible memory usage: 3.5G (11% of installed RAM) [OK] Slow queries: 0% (0/62K) [OK] Highest usage of available connections: 5% (9/151) [OK] Key buffer size / total MyISAM indexes: 16.0M/103.0K [OK] Key buffer hit rate: 100.0% (2K cached / 0 reads) [OK] Query cache efficiency: 57.8% (35K cached / 60K selects) [!!] Query cache prunes per day: 153440 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2K sorts) [OK] Temporary tables created on disk: 22% (3K on disk / 14K total) [OK] Thread cache hit rate: 97% (10 created / 484 connections) [OK] Table cache hit rate: 94% (129 open / 136 opened) [OK] Open file limit used: 1% (20/1K) [OK] Table locks acquired immediately: 100% (49K immediate / 49K locks) [!!] InnoDB buffer pool / data size: 3.0G/10.3G [OK] InnoDB log waits: 0 -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Enable the slow query log to troubleshoot bad queries Variables to adjust: query_cache_size (> 16M) innodb_buffer_pool_size (>= 10G)

На оригинальном сервере всё работает именно так и не тормозит. То же самое без обновлений на новом сервере. Предложенные оптимизации не помогают

Goldsman ()
Ответ на: комментарий от Goldsman

Может быть на старом сервере временные таблицы создавались на SSD, на новом на HDD https://dev.mysql.com/doc/refman/5.5/en/temporary-files.html Но это не объясняет повышеную загрузку процессора. Вообще, такие запросы нужно соптимизировать. Ну или хоть увеличить tmp_table_size/max_heap_table_size

goingUp ★★★★★ ()
Последнее исправление: goingUp (всего исправлений: 2)
Ответ на: комментарий от goingUp

На новом сервере все точки монтирования на одном SSD, HDD никак не задействованы. На прежнем сервере /var живёт на жестком диске, остальное на SSD. Сейчас на новом сервере на одном ssd всё работает быстро, но система старая. Либо не париться и идти по принципу - работает-не трогай и переживать за дырки в безопасности, либо решать проблему точечно обновляя пакеты.

Goldsman ()
Ответ на: комментарий от goingUp

По поводу оптимизации - увеличение tmp_table_size/max_heap_table_size улучшит ситуацию, но эффекта «вау» не будет, так как само приложение и его запросы довольно таки тяжелые. Всё это уже переписывается и переделывается заного и по нормальному. Пока этот процесс идёт, прежняя версия должна нормально работать в исходном виде, в безопасной среде с поправками на то, что теперь сервер смотрит в интернет напрямую

Goldsman ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.