LINUX.ORG.RU
решено ФорумAdmin

Наглядное сравнение I/O

 , , ,


2

2

Исходные данные:
Есть сервер логов, который упирается в I/O
Я предполагаю, что возможно ситуацию можно несколько улучшить изменением стратегии хранения данных и более агрессивным сжатием (ибо по CPU есть большой запас)

Задача:
Найти способ наглядного сравнения использования I/O на конкретном разделе. Так как выигрыш будет скорее всего не очень большим то нужна хорошая наглядность, идеальным вариантом мне видится наложение графиков.

Доступные средства:
Из коробки на сервере есть atop(по которому и выявлен bottleneck), смысл показаний и способ использования которого мне пока не очень ясны.То ли нужно задействовать абстрактный busy%, то ли конкретные цифры TPS - хз
Задача разовая, поэтому монстры мониторинга не велкам, однострочники на перле - велкам

★★★★★

zfs со сжатием туда и рамы под кэш побольше

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

Ок, добавим входных данных.
SLES 11, ext3,ядро 2.6, оперативки 96Gb

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

оперативки 96Gb

логи пиши в оперативку, параллельно в фоне сжимай и скидывай на диск.

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

логи пиши в оперативку

разумное предложение
Нужно ещё исходных данных.
Их есть у меня:
сервер резервируется (это нода кластера), питание резервируется, раздел - RAID5, примонтированный по FC с дискового массива.
Потеря логов неприемлема.

Какие есть варианты обеспечения сохранности данных в оперативке при различных сценариях отказа?

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

Какие есть варианты обеспечения сохранности данных в оперативке при различных сценариях отказа?

Считай что ramdisk == дисковый кеш (в оперативке который)

Вывод: быстрая обработка (сжатие) и сброс на диск. В оперативке минимум того что можно потерять в случае внезапной паники ядра (остальное у тебя дублируется). Собственно и логи надо бы раздуплить на два сервера.

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

В оперативке минимум того что можно потерять

какой процент из 96 гигов составляет этот минимум?

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

минимум зто то что еще не сжато и не сброшенно на диск. Т. к. CPU свободен, то сжатие текстовых логов даст снижение дискового IO и система будет справляться со своими обязанностями лучше чем сейчас

как вариант, сжимать в логгере и на диск писать уже «бинарный» лог

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

у тебя

сервер логов, который упирается в I/O

т. е. или тормозится процесс, генерирующий логи, либо где-то есть очередь в оперативке, которая может быть потеряна.

Так что не задавай мне наивных вопросов

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

Слать данные в локальной сети на другой сервер который будет заниматься только сохранением логов, обеспечив ему независимое питание + ибп.

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

Раз уж мы так углубились, то нужно ещё исходных данных
Сервер собирает логи с других серверов по sftp (удаляя забранное), парсит, сортирует их итд. Это не syslog сервер, логи текстовые

zolden ★★★★★ ()

iostat -x показывает много характеристик: операций в секунду, килобайт в секунду, среднее время обслуживания и среднюю длину очереди. а также комплексную характеристику: процент утилизации. Из каких соображений он его считает, правда, не знаю.

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

парсит, сортирует их итд

ну либо ты добавляешь в конце цепочки сжатие для уменьшения IO либо наращиваешь IO. Какие еще варианты? добавить еще сервер слишком банально и очевидно

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

ну либо ты добавляешь в конце цепочки сжатие для уменьшения IO либо наращиваешь IO. Какие еще варианты?

Я не говорю об прорывных улучшениях.
В идеале мне хватило бы всего несколько процентов выигрыша, чтобы сгладить пики I/O.
Если мы закончили обсуждать варианты с изменением архитектуры/конфигурации железа, то можно было бы вернуться к моему изначальному вопросу, например

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

Выше уже сказали - iostat. По его выхлопу можно любым офисом графики строить.

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

про iostat думал, но были сомнения про сбор статистики за длительный период.
но гугл спас отца русской демократии, спасибо за вектор

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

Сервер собирает логи с других серверов по sftp (удаляя забранное), парсит, сортирует их итд

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

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

Да, это бесспорно интересный вариант, но он требует изменения софта и серьёзного тестирования, чтобы реализовать подобный механизм транзакций.
К примеру, я сходу даже не скажу, как должна вести себя эта связка если сервер с исходными логами ушёл в ребут пока его файл обрабатывались.
Очевидно, нужен журнал транзакций. Но каковы его параметры?
В общем это не минутный вопрос.

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

К примеру, я сходу даже не скажу, как должна вести себя эта связка если сервер с исходными логами ушёл в ребут пока его файл обрабатывались

Сервер логов продолжает идти по алгоритму, а когда дойдёт до удаления исходного файла то пытается заново подключиться (в любом случае нет нужды оставлять открытое соединение по завершении скачивания) к серверу-логописателю (пытается пока не получится) и удаляет файл.
Тут-то как-раз и писать почти ничего не надо, только обработку ошибки подключения к поставщику логов.

Интереснее сценарий когда на одном из этапов работы дохнет сам сервер обрабатывающий логи. Но думаю и тут можно обойтись без дополнительных сущностей. Как сервер узнаёт что где-то какие-то логи надо скачать и обработать? Обходит все сервера и если находит неудалённые логи то тырит их? Тогда если файл есть на сервере-логописателе то это либо новый файл (и его надо скачать и обработать) либо файл который не удалось обработать когда-то раньше (и его надо скачать и обработать). т.е. монопенисуально. Надо только добиться атомарности (или чего-то вроде атомарности) для сдвоенной операции «записать обработанные логи над диск и удалить исходные с удалённого сервера». «Записать обработанные логи над диск» можно заменить на «переименовать ранее записанный файл» (данные пишутся во временный файл на том-же разделе где будут храниться, потом файл переименовывается).
Алгоритм такой: попытаться удалить файл с удалённого сервера, если получиться то переименовать файл на диске. Потеря данных возможна, но только если что-то навернётся в короткий промежуток времени между нужный на две эти операции. Хотя если этот алгоритм будет отрабатывать достаточно часто, и ломаться будет что-то достаточно часто, то достаточно скоро эти события совпадут. Можно посчитать вероятность того что за некоторый период времени будет хотя-бы одна потеря информации, правда я сейчас не соображу как именно это посчитать.

Сори за поток сознания.

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

iostat

уточни плиз

apt-cache search iostat
sysstat - system performance tools for Linux
dstat - versatile resource statistics tool
ganglia-modules-linux - Ganglia extra modules for Linux (IO, filesystems, multicpu)
ifstat - InterFace STATistics Monitoring
nicstat - print network traffic statistics
pcp-import-iostat2pcp - Tool for importing data from iostat into PCP archive logs
r-cran-epi - GNU R epidemiological analysis
r-cran-epibasix - GNU R Elementary Epidemiological Functions
r-cran-rms - GNU R regression modeling strategies by Frank Harrell

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

при различных сценариях отказа?

раньше продавались аппаратные рам-диски с батарейкой на борту

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

Сценарий:
Я ошибся при установке обновлений, разбил клавиатуру об монитор, в итоге сервер ушёл в ребут, кластер переключился на вторую ноду

Продолжите фразу:
Аппаратный рам-диск с батарейкой на борту поможет тут следующим образом ...

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

ставим аппаратный рам-диск на обе ноды, с запасной ноды экспортируем аппаратный рам-диск в виде блочного устройства по сети, собираем из локального и импортированного рам-диска зеркало.

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

тем, что данные останутся на рам-диске?

и ведь и не поспоришь...

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

и ведь и не поспоришь

аппаратный рам-диск с батарейкой будет для системы выглядеть как обычное блочное устройство, а инструменты чтобы синхронизировать его с нодами кластера на ваш выбор.

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

Переливаете из пустого в порожнее.

аппаратный рам-диск с батарейкой — железо, которое в самый нужный момент сломается, батерейка потеряет емкость, ...

Решение уже было дано: не удалять лог с источника пока его копия не будет обработана и сохранена. При внештатной ситуации, наличие лога на источнике означает незавершенность транзакции — и ее надо повторить.

Никаких журналов не надо. Никакого особого железа не надо. Особых изменений тоже почти нет. Переместить операцию удаления в конец цепочки и дополнить обход источников проверкой на «не удаленные логи» как признак незавершенных транзакций

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

аппаратный рам-диск с батарейкой — железо, которое в самый нужный момент сломается, батерейка потеряет емкость

с этой же вероятностью может сломаться любая железка на ноде,выход из строя рам-дисков сразу на двух и более нод маловероятен

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

Выход из строя и ноды и лог сервера одновременно так же мало вероятен как и двух рам-дисков сразу

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

У меня уже есть довольно быстрый массив на SAS дисках, LUN с которого доступен на обеих нодах как обычное блочное устройство
Ньюанс в том что пишет/читает с него сотня процессов кучу разных небольших файлов, то есть это худший из возможных сценариев I/O - абсолютный random
При этом производительности хватает 99% времени, есть очень кратковременные пики когда busy% прыгает до ~100 и которые я бы хотел попробовать сгладить, при этом LA всё равно остаётся порядка 1.5 (на 32-ядерной железке)
Рам-диск тут пока кажется излишним

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

Рам-диск и SAS не вижу связи для аналогии, аппартный рам-диск это устройство состоящие из аппаратной оперативной памяти

axelroot ()
Последнее исправление: axelroot (всего исправлений: 1)
Ответ на: комментарий от anonymous

Никаких журналов не надо. Никакого особого железа не надо. Особых изменений тоже почти нет

Мм..не факт...хотя идея и интересная, но надо всё тестировать чтобы не упереться в неожиданный bottleneck
В идеале и сильно упрощённо всё выглядит конечно просто
1. Процесс-обработчик1 забирает лог_Х с remotehost
2. Процесс-обработчик2 обрабатывает лог_Х, по окончанию работы даёт сигнал процессу3
3. Процесс-обработчик3 удаляет лог_Х с remotehost

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

Процесс-обработчик3 удаляет лог_Х с remotehost

а тут вырубит питание и лог не успеет удалиться, и при восстановлении ноды обработается еще раз, в таких цепочках всегда вылезают неожиданности.

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

Я бы не сказал, что это неожиданность.
Это по сути неподтверждённая транзакция, логично провести её ещё раз
Вопрос с исключением дублирования конечно надо будет прорабатывать

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

Для начала надо прикинуть какой процент времени система будет находиться в неконсистентом состоянии, и следовательно какова вероятность дублирования данных при выходе из строя одного из её элементов. Если вероятность слишком высока то надо что-то дополнительно «подпирать», либо уменьшать продолжительность неконсистентного состояния.

P.S. правильно я понимаю что нельзя «дёшево» реализовать одновременную запись в разделяемый дисковый массив обоими серверами?

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

Процент времени думаю порядка 0.001%

Кластер - Active/Standby, всё решение на это заточено, задёшево переделать нельзя.

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

Процент времени думаю порядка 0.001%

Это ты посчитал или с потолка? Сколько в среднем занимает одна этерация (сачать-обработать-записать-удалить), сколько одновременно происходит этераций, сколько занимает удаление и переименование (тут надо заложить запас на непредсказуемость сетевых задержек)?

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

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

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