Какие существуют проблемы в круглосуточной работе программ?
день добрый!
нагрузили меня задачей «анализ методов обеспечения целостности программ и баз данных на оборудовании, которое работает круглосуточно». Но для рассмотрения методов нужно понять, какие проблемы вообще существуют при круглосутчной работе программ. Первая такая проблема, что приходит мне в голову — утечка памяти, может еще хардверные отказы (типа винт сгорел на ходу).
Прошу знающих, кто сталкивался на практике, помочь с определением возможных проблем. Гугл мне, к сожалению, не сильно помог
Заранее спасибо!
62 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівНо с другой стороны бывают же ситуации что есть какая то бага, которую не могут воспроизвести на дев машине, только логи и могут пролить свет.
Вообще без логов конечно никуда, но сильно они не помогают, так как являются самым низкоэффективным способом поиска ошибок и контроля состояния программы — я бы сравнил их с ситуацией, когда кто-то с помощью запоминающего осциллографа будет пытаться отладить программу тыкаясь в мамку — теоретически это можно, но практически это нецелесообразный путь. Успешные высоконагруженные проекты являются таковыми именно из-за применения специально заточенной под эти задачи программной архитектуры, которая кроме всего прочего позволяет наблюдать приложение и его поведение _снаружи_ имея одновременно доступ к его ключевым статистическим структурам.
В embedded конечно логи собирать вряд ли получится, но в нагруженных веб проектах логи вполне можно собирать и потом анализировать с помощью правильного инструментария.
Сильно зависит от приложения — такое, которое требует внимания к управлению/менеджеру памяти обычно является высоконагруженным, для многих лог бесполезен, так как критическая ситуация может наблюдаться раз в несколько месяцев, а события происходить, скажем, каждые 100 миллисекунд — как потом в этом логе ковыряться? Например у меня как-то был проект — RT система управления телефонной станцией (один модуль/комп обслуживает 2 тыс. абонентов) — там события происходят по 1 ms таймеру, даже если бы теоретически (ПО в этом случае не прошло бы никакую сертификацию) можно было наплевать на джиттер и писать логи, то в то время (2000 год) таких винтов даже в природе не было. А для тех кого еще эта тема не утомила: догадайтесь с трех раз под какой ОС и с каким менеджером памяти это работает?;)
> by Olexiy: Мета-проблема: як дізнатись, що у тебе проблеми. Що і як моніторити, куди дивитись, т.п. Мета-мета-проблема: зламався моніторинг.
+100
Я не участвовал в разработке критичных систем, как, например, в авиационной промышленности, но, опыт в круглосуточно действующем ПО есть.
Нужно делать такие логи, чтобы потом их можно было прочесть и понять, а не 10 млн. строк непонятных, непоследовательных/перемешанных сообщений в одном файле. Как вариант — несколько/много лог-файлов разного назначения и детализации, с учетом паралельности процессов и без. Опять же, все зависит от конкретного ПО, где-то это будет излишне. Где-то — очень специфично, вплоть до параллельного сохранения логов в БД.
Мониторить состояние системы, и в случае подозрительных показателей (напр., объем диска, падение производительности SQL запросов) отправлять сообщения — email, SMS, и т.д. При этом, если приложение очень критичное — нужно также делать параллельный независимый мониторинг.
Вообще, для очень надежных приложений нужен и надежный бюджет, и уравновешенный менеджмент, и хорошая команда, масса юнит тестов и прочего тестирования, code review, нормальный круглосуточный саппорт, а не ситуации “код нужен был вчера” и, как следствие, наскоро слепленный и не протестированный как следует результат (с такими же “кривыми” логами). Это не менее важно чем само проектирование ПО.
P.S. Вот, кстати, книжка интересная об ошибках в ПО — citforum.ru/...bug/index.shtml (Аппарат для исследования климата Марса и проч.)
> помочь с определением возможных проблем...
Если это не одна машина, а несколько, и между ними есть продолжительные соединения, например с БД или каким-нибудь другим сервисом, то соединение может отвалиться (по разным причинам), это нужно учитывать и уметь восстанавливаться или же избегать продолжительных соединений.
В конце концов сошлись на «а почему бы и не применять специализированный malloc () /free ()? »
У меня вопрос к [некоторым] участникам дискуссии -
«а что же, собственно, в этом такого странного/сложного/...,
что такое решение изначально расценивалось как необычное/сложное/странное/...? ».
Насколько я помню свои впечатления, да, меня настолько покоробил подход к освобожденной памяти, что переделал (сделал с нуля) этот модуль библиотеки.
Увы, в контексте обсуждаемых проблем результат был «скорее отрицательнвм» — желаемого роста производительности не произошло (впрочем, там вообще был очень уж специфический случай).
кстати еще одна из угроз/проблем — уязвимости по.
по-моему, тут она озвучена не была
2kelwor:
С тебя бутылка!:)
А о каких конкретно продуктах здесь идет речь?
всем огромнейшее спасибо, курсач сдан хорошо:)
Капец, форум превратился в холивар линуксоидов: (
Не думаю что кто-то там за что-то хватался — memory pool абстракция есть с самого рождения и в glibc (man obstacks). Разработчики апача, (например также как и Монти реализовал свою thread абстракцию в mysql) должны были обеспечить кроссплатформенность для своего приложения.
Есть, все верно — в kernel space свой менеджер памяти, в юзер space свой. Каждый из них решает свои задачи, так как оперируют они характерными типами памяти — зоново-архитектурно зависимой в первом случае и
але чомусь мені здається, що менеджер пам’яті є складової ядра ОС.
Поправте, якщо помиляюсь.
Да как хочешь... докажи ещё это Торвальдсу и жизнь будет прожита не зря:)
Какая разница серверному приложению, что new будет выполняться 0.0005 сек или 0.5 секунды? Никакой, кроме общей потери производительности... Тото ребята из апача за голову хватались..., но они не знали, наверное, что встроенный аллокатор рулит. Не донесли им весть.
Так, авжеж:)
Linux — это только ядро, бесполезно-напористый ты наш. Кроме glibc, к твоему сведению, у Linux еще есть много user-space вариантов (bionic/uclibc/dietlibc/newlibc/etc.). Или опять будем считать все это «жестоким порождением»?
Вынужден разочаровать вдвойне — во-первых нужна, а во-вторых все прекрасно работает годами беэ этих ненужных ухищрений. Или может есть желание поспорить с серверными решениями от RedHat/IBM/Oracle и им подобных, которые, вот ведь незадача, используют glibc вместе с таким вот херовым алокатором и uptime там пучком?
Даже не удивляюсь — видеть и/или понимать, а тем более с умом применять это, видите ли, совсем разные вещи.
Спасибо, я посмотрю сегодня.
Please let me know if something wrong with this implementation as I really want to understand issue with memory allocation in linux you mentioned earlier. Thanks.
Огласите весь список пожалуйста:) Можно исходник?
Exactly the same (~60%).
Какой был memory usage при старте и после 1 часа работы?
glibc — такое же порождение линукса, ибо другим не нужен. И так же чётко ассоциируется c Линуксом. Почему я тогда понял ScorpZ, а ты нет? Догадливый ты наш...
Этим 99% програм не нужна предсказуемость и прогнозируемость выполнения. Зануда абсолютно прав на счёт статического выделение или пре-аллоцирования при старте.
Я в линуксе вообще ничего нормального не вижу по дефолту, хотя эта «нормализация» должна была появится лет 10 назад.
cpu usage: ~70%
memory usage: ~60%
up time: ~9 hours
kernel: 2.6.32
linux allocator: SLAB
toolchain: CodeCourcery 2010q1−202
g++: 4.4.1
libstdc++: 6.0.12
libc: 2.11.1
Board is still working.
Влом. ну да. вообще-то написание серверов это отдельное направление «мысли»...
Рулит и бибикает инженерный подход к разработке программ. В настоящий момент чаще наблюдается тенденция пассивного ожидания, что мир должен прогнутся под программиста и его программу. Можно отметить, что реальность сурова к такого рода ожиданиям;)
если же поковырять дотнет или жабу, то там довольно извращенные алгоритмы именно для борьбы с фрагментацией, так там хоть можно более гибко «двигать» куски памяти.,
но я бы всетаки правил логику программы, «другой аллокатор» это костыль
Я как минимум 1 раз сталкивался с проектом, где был использован другой (отличный от glibc’шного) аллокатор. Так что видимо не всех он устраивает. А вообще, статическое выделение памяти рулит и бибикает.
Невнимательный вы наш — про версии и слова не было — ScorpZ заявил про «стандартный линуксовый алокатор», на что было замечено что Linux — это в первую очередь ядро. Или все еще грызут сомнения по этому поводу?
Угм, могу сказать то же самое.
Говорить желательно по делу и/или приводить конкретные аргументы. Пока наблюдается логическая нестыковка — 100% программ из репозиториев RedHat/Debian/Slackware/Sisyphus/Ubuntu/etc. glibc алокатор вполне устраивает. Скажу даже больше — он устраивает еще 99% программ которые не входят в эти репозитории. А то что 2 программистов из этого форума он не устраивает, так это IMHO дело кривых рук этих же самых программистов — если задачу решать влоб, то тут никакой алокатор не поможет, так как дело в консерватории.
Если бы это было правдой, то мы бы видели их наличие в libc библиотеках by default. К счастью это не так.
Еще раз. ScorpZ ничего про ядро и не говорил. Его версию начал спрашивать ты.
Смело. Обычно так говорят те, кто никогда раньше об этом даже понятия не имел.
Т.е. таки ты теперь разрешаешь ScorpZ использовать другой аллокатор?:)
Дело должно быть не в IMHO, а в опыте. Многие варианты быстрее, надёжнее и лучше.
Сталкивался с: — заканчивалось место на винтах (один из случаев — росли дампы БД) — заканчивались сроки сертификатов — падали каналы (ваша прога может быть к этому не готова) — зависали сессии, в том числе и по вине Cisco ASA (по дефолту рубал неактивные в течении 1 часа) — заканчивался срок действия пароля юзера по дефолтному профилю в Оракл 11 (6 мес.) — самопроизвольный выход из строя узлов кластера Oracle — разсинхронизация времени между узлами кластера Oracle — переход в новый год (не предусмотрели сброс счетчика нумерации документов) — накопление мусора нашим приложением в файловой системе (из 20 000 файлов полезных оказалось около 2 000) — накопление ошибки вычисления интервала запуска — ухудшение производительности из-за накопления большого количества данных — ухудшение производительности из-за увеличения количества пользователей — выключение серверов из-за перегрева — зависание сложных запросов в БД...
Glibc алокатор представляет собой прекрасный компромисс между скоростью и применимостью в 99% приложений, что подтверждается неоспоримой практикой. Если же приложение написано не совсем прямо (например невзирая на фундаментальное понятие x86 архитектуры под названием PAGE_SIZE) — то и в этом случае алокатор справляется со своей задачей, правда отгрызет от heap необходимый кусок для буферирования эффекта фрагментации. Первое, что следует сделать — исправить ошибку в архитектуре приложения и ДНК разработчика. Также можно подтюнинговать стандартный алокатор (man mallopt), использовать альтернативный или написать свой, for ex.:
www.ibm.com/...brary/l-memory
Мое IMHO — варианты кроме glibc будут конкретно медленней и/или глючней.
glib 2.5, ядро — 2.6.18
Выделяем X блоков (пусть будет 1024) рандомного размера (пусть будет от 1 до 4194304, смотря сколько памяти на машине). Сохраняем указатели в массив. Затем рандомно выбираем элемент массива, релизим его и выделяем на это место новый рандомный кусок. Обязательно делать memset () для выделенного куска, либо сalloc (). Работать определённое количество времени (где-то час, если не свалится процесс раньше), после релизнуть все выделенные куски памяти и заснуть на долго. Всегда хранить количество общей выделенной памяти, её максимальное значение, чтобы затем проверять соответствие. Смотрим теперь информацию по процессу.
Странно, максимум, что у меня творили и маллоки, и С++ аллокаторы — это работали по шлемюэлю, когда через некоторое время начинали дефрагментировать память и одно из выделений памяти происходило медленно до конца дефрагментации.
Т.к. баг очень нехороший, буду Вам благодарен, если подскажете как воспроизвести эту ситуацию (какое ядро и из какого репозитария, какой аллокатор, какая версия g++ и какие библиотеки). Заранее спасибо.
А, уже вчитався, memset здався Маллоком
А чому delete [] p,
а не free (p)?
ну раз ясно, так курите glibc маны
ясно же, что речь о glibc
Можно побеседовать и о GC стандартной библиотеки libc, то тут нужно конкретно уточнить — о какой же именно libc пойдет речь.
Вывод: как уже было совершенно верно подмечено — нефиг на аллокатор пенять, да еще на «стандартный линуксовый
трактор»Проблема одна — спать не дают:)
Фізичні проблеми: вимкнулось живлення, проблеми у провайдера, хтось натиснув не ту кнопочку, пожежа, щось згоріло в компі.
Проблеми з софтом: великий наплив користувачів (слешдот-ефект, наприклад), необхідність оновити версію програми, оновити ліби, відновитись з бекапу, замінити сервер (и).
Специфічні проблеми: логи/бекапи займають весь вінчестер, не вистачає памяті / інших ресурсів, невчасно включився гарбадж коллектор:)
Мета-проблема: як дізнатись, що у тебе проблеми. Що і як моніторити, куди дивитись, т.п.
Мета-мета-проблема: зламався моніторинг.
Веселуха, коротше:)
Просто у стандартного линуксового аллокатора отсутствует дефрагментация памяти, поэтому приложение, которое часто выделяет/высвобождает память рано или поздно зажрет всю доступную память. Поэтому мы решили использовать альтернативный аллокатор памяти. То же самое приложение работает по несколько месяцев и объем занимаемой памяти остается стабильным.
Це величезна необ’ємна область яка включає рівень Hardware, Software & Operations.
Архітектура такої аплікації описується наприклад в SaaS maturity level 4 і складається з хардварного кластерного лоадбалансера, кластерного аплікейшн сервера з реплікацією сесії і фейловером ну і звісно кластером сервера баз даних. Хоча це лише один з прикладів реалізації такої системи на софтверному і частково на хардверному рівні.
Правильная настройка crond + «прямой» конфиг для logrotate спасёт отца русской демократии.:)
Логи могут расти быстрее чем будет работать logrotate.
Это классическая ситуация в Линуксе.
P.S. Хотя да, для исследования это одна из проблем, на которую следует обратить внимание.
100% аптайма никто не гарантирует. Но, если использовать кластер минимум из двух серверов, и вместо одного жесткого диска — RAID массив с соответствующей цифрой — то, если сбойнет или упадет одно оборудование — другое его будет дублировать. Гуглить можно по словам «кластер», «RAID»
И т.д. Первых двух достаточно, это проблема.
Эээ... Вы уверены? А что за библиотека и какая версия? Просто такая ситуация, как бы это сказать... даже не баг, это слон.:)
Применительно к промышелнности должен быть еще и третий челвоек, которому будут разрывать пасть, если первые 2 сработают, ибо металл, застрявший в валках прокатного стана = новым валкам, они дорогиииие.
Можно упасть его и позже и перезагрузить, главное, чтобы в критических процессах не произошел останов из — за этого, не?
Тестили валгриндом от, а до я, никаких утечек, память после delete не высвобождается.
Например -
//—
char *p = new char [1024 * 1024];
memset (p, 0, 1024 * 1024); // память (физическая) процесса зажралась на метр
delete [] p; // память процесса нифига не уменьшилась
char *p = new char [1024 * 1024];
memset (p, 0, 1024 * 1024); // память (физическая) процесса зажралась еще на метр
//—
Поменяли аллокатор, ситуация изменилась...
При круглосуточной работе программ, главное чтоб рядом всегда был человек, который знает где находиться кнопка reset. В особо запущенных случая, должен еще быть человек который знает где находиться рубильник питания.
Valgrind вам в помощь... И нечего на линукс пенять...
Так, например, прога которую мы пишем постоянно выделяет/высвобождает память. Но так, как стандартный линух-аллокатор нормально не дефрагментирует память, то со временем память процесса выростает до огромных размеров и система его килляет. Хотя в проге никаких утечек нету, просто память после free/delete реально не высвобождается, пришлось искать альтернативные аллокаторы.
Автоапдейт с авторебутом любого софта
www.computerworld.com/..._Best_practices
можно попасть впросак, когда система «делает вид что работает».
с другой стороны, надо смотреть на конкретную задачу и требования кастомера.
Вообще лимит любых ресурсов. Память, адресное пространство процесса, хэндлы, свободное место файловой системы, etc.
Лучшие собаководы рекомендуют чтобы оно всё-таки упало.
Остутствие обработки эксепшнов так, чтобы программа после эксепшна не валилась в кору, а восстанавливала свое состояние и продолжала работу.
Counters overflow, logs rotation required, Switch to summer time
Веерное отключение электричества, мыши, перегрызающие витую пару или уборщица со шваброй, истечение срока лицензии, сгорел винт, монитор, мамка, процессор (в смысле пожар был)