Навчання · 6 грудня 2010, 22:14 132

kelwor

Какие существуют проблемы в круглосуточной работе программ?

день добрый!

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

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

Заранее спасибо!

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

crypto5 11.12.2010 06:51

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

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

Відповісти

Підтримати

anonymous 11.12.2010 06:37

Вообще без логов конечно никуда, но сильно они не помогают, так как являются самым низкоэффективным способом поиска ошибок и контроля состояния программы — я бы сравнил их с ситуацией, когда кто-то с помощью запоминающего осциллографа будет пытаться отладить программу тыкаясь в мамку — теоретически это можно, но практически это нецелесообразный путь. Успешные высоконагруженные проекты являются таковыми именно из-за применения специально заточенной под эти задачи программной архитектуры, которая кроме всего прочего позволяет наблюдать приложение и его поведение _снаружи_ имея одновременно доступ к его ключевым статистическим структурам.

Відповісти

Підтримати

crypto5 11.12.2010 06:23

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

Відповісти

Підтримати

anonymous 11.12.2010 06:11

Сильно зависит от приложения — такое, которое требует внимания к управлению/менеджеру памяти обычно является высоконагруженным, для многих лог бесполезен, так как критическая ситуация может наблюдаться раз в несколько месяцев, а события происходить, скажем, каждые 100 миллисекунд — как потом в этом логе ковыряться? Например у меня как-то был проект — RT система управления телефонной станцией (один модуль/комп обслуживает 2 тыс. абонентов) — там события происходят по 1 ms таймеру, даже если бы теоретически (ПО в этом случае не прошло бы никакую сертификацию) можно было наплевать на джиттер и писать логи, то в то время (2000 год) таких винтов даже в природе не было. А для тех кого еще эта тема не утомила: догадайтесь с трех раз под какой ОС и с каким менеджером памяти это работает?;)

Відповісти

Підтримати

anonymous 10.12.2010 21:14

> by Olexiy: Мета-проблема: як дізнатись, що у тебе проблеми. Що і як моніторити, куди дивитись, т.п. Мета-мета-проблема: зламався моніторинг.
+100
Я не участвовал в разработке критичных систем, как, например, в авиационной промышленности, но, опыт в круглосуточно действующем ПО есть.
Нужно делать такие логи, чтобы потом их можно было прочесть и понять, а не 10 млн. строк непонятных, непоследовательных/перемешанных сообщений в одном файле. Как вариант — несколько/много лог-файлов разного назначения и детализации, с учетом паралельности процессов и без. Опять же, все зависит от конкретного ПО, где-то это будет излишне. Где-то — очень специфично, вплоть до параллельного сохранения логов в БД.
Мониторить состояние системы, и в случае подозрительных показателей (напр., объем диска, падение производительности SQL запросов) отправлять сообщения — email, SMS, и т.д. При этом, если приложение очень критичное — нужно также делать параллельный независимый мониторинг.
Вообще, для очень надежных приложений нужен и надежный бюджет, и уравновешенный менеджмент, и хорошая команда, масса юнит тестов и прочего тестирования, code review, нормальный круглосуточный саппорт, а не ситуации “код нужен был вчера” и, как следствие, наскоро слепленный и не протестированный как следует результат (с такими же “кривыми” логами). Это не менее важно чем само проектирование ПО.
P.S. Вот, кстати, книжка интересная об ошибках в ПО — citforum.ru/...bug/index.shtml (Аппарат для исследования климата Марса и проч.)

Відповісти

Підтримати

anonymous 10.12.2010 20:49

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

Відповісти

Підтримати

Володимир 10.12.2010 20:28

Интересно.
В конце концов сошлись на «а почему бы и не применять специализированный malloc () /free ()? »
У меня вопрос к [некоторым] участникам дискуссии -
«а что же, собственно, в этом такого странного/сложного/...,
что такое решение изначально расценивалось как необычное/сложное/странное/...? ».
Насколько я помню свои впечатления, да, меня настолько покоробил подход к освобожденной памяти, что переделал (сделал с нуля) этот модуль библиотеки.

Увы, в контексте обсуждаемых проблем результат был «скорее отрицательнвм» — желаемого роста производительности не произошло (впрочем, там вообще был очень уж специфический случай).

Відповісти

Підтримати

kelwor 09.12.2010 19:23

окай:)
кстати еще одна из угроз/проблем — уязвимости по.

по-моему, тут она озвучена не была

Відповісти

Підтримати

anonymous 09.12.2010 19:12

2kelwor:

всем огромнейшее спасибо, курсач сдан хорошо:)

С тебя бутылка!:)

Відповісти

Підтримати

crypto5 09.12.2010 19:04

Или может есть желание поспорить с серверными решениями от RedHat/IBM/Oracle и им подобных, которые, вот ведь незадача, используют glibc вместе с таким вот херовым алокатором и uptime там пучком?

А о каких конкретно продуктах здесь идет речь?

Відповісти

Підтримати

kelwor 09.12.2010 19:01

всем огромнейшее спасибо, курсач сдан хорошо:)

Відповісти

Підтримати

anonymous 09.12.2010 15:22

Капец, форум превратился в холивар линуксоидов: (

Відповісти

Підтримати

anonymous 09.12.2010 13:53

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

Не думаю что кто-то там за что-то хватался — memory pool абстракция есть с самого рождения и в glibc (man obstacks). Разработчики апача, (например также как и Монти реализовал свою thread абстракцию в mysql) должны были обеспечить кроссплатформенность для своего приложения.

Перепрошую, шановне товариство, що такий дилетант по люніксах влазить в диспут,
але чомусь мені здається, що менеджер пам’яті є складової ядра ОС.
Поправте, якщо помиляюсь.

Есть, все верно — в kernel space свой менеджер памяти, в юзер space свой. Каждый из них решает свои задачи, так как оперируют они характерными типами памяти — зоново-архитектурно зависимой в первом случае и

Відповісти

Підтримати

anonymous 09.12.2010 10:15

Linux — это только ядро, бесполезно-напористый ты наш. Кроме glibc, к твоему сведению, у Linux еще есть много user-space вариантов (bionic/uclibc/dietlibc/newlibc/etc.). Или опять будем считать все это “жестоким порождением”?

Перепрошую, шановне товариство, що такий дилетант по люніксах влазить в диспут,
але чомусь мені здається, що менеджер пам’яті є складової ядра ОС.

Поправте, якщо помиляюсь.

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 09.12.2010 09:40

Linux — это только ядро, бесполезно-напористый ты наш. Кроме glibc, к твоему сведению, у Linux еще есть много user-space вариантов (bionic/uclibc/dietlibc/newlibc/etc.). Или опять будем считать все это «жестоким порождением»?

Да как хочешь... докажи ещё это Торвальдсу и жизнь будет прожита не зря:)

Вынужден разочаровать вдвойне — во-первых нужна, а во-вторых все прекрасно работает годами беэ этих ненужных ухищрений. Или может есть желание поспорить с серверными решениями от RedHat/IBM/Oracle и им подобных, которые, вот ведь незадача, используют glibc вместе с таким вот херовым алокатором и uptime там пучком?

Какая разница серверному приложению, что new будет выполняться 0.0005 сек или 0.5 секунды? Никакой, кроме общей потери производительности... Тото ребята из апача за голову хватались..., но они не знали, наверное, что встроенный аллокатор рулит. Не донесли им весть.

Даже не удивляюсь — видеть и/или понимать, а тем более с умом применять это, видите ли, совсем разные вещи.

Так, авжеж:)

Відповісти

Підтримати

anonymous 09.12.2010 09:27

glibc — такое же порождение линукса, ибо другим не нужен. И так же чётко ассоциируется c Линуксом. Почему я тогда понял ScorpZ, а ты нет? Догадливый ты наш...

Linux — это только ядро, бесполезно-напористый ты наш. Кроме glibc, к твоему сведению, у Linux еще есть много user-space вариантов (bionic/uclibc/dietlibc/newlibc/etc.). Или опять будем считать все это «жестоким порождением»?

Этим 99% програм не нужна предсказуемость и прогнозируемость выполнения. Зануда абсолютно прав на счёт статического выделение или пре-аллоцирования при старте.

Вынужден разочаровать вдвойне — во-первых нужна, а во-вторых все прекрасно работает годами беэ этих ненужных ухищрений. Или может есть желание поспорить с серверными решениями от RedHat/IBM/Oracle и им подобных, которые, вот ведь незадача, используют glibc вместе с таким вот херовым алокатором и uptime там пучком?

Я в линуксе вообще ничего нормального не вижу по дефолту, хотя эта «нормализация» должна была появится лет 10 назад.

Даже не удивляюсь — видеть и/или понимать, а тем более с умом применять это, видите ли, совсем разные вещи.

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 09.12.2010 07:52

Спасибо, я посмотрю сегодня.

Відповісти

Підтримати

anonymous 09.12.2010 07:24

Можно исходник?

Sure. pastebin.com/bGrbUyyq

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.

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 09.12.2010 07:07

Exactly the same (~60%).

Огласите весь список пожалуйста:) Можно исходник?

Відповісти

Підтримати

anonymous 09.12.2010 06:44

Какой был memory usage при старте и после 1 часа работы?

Exactly the same (~60%).

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 09.12.2010 06:42

Board is still working.

Какой был memory usage при старте и после 1 часа работы?

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 09.12.2010 06:40

Невнимательный вы наш — про версии и слова не было — ScorpZ заявил про «стандартный линуксовый алокатор», на что было замечено что Linux — это в первую очередь ядро. Или все еще грызут сомнения по этому поводу?

glibc — такое же порождение линукса, ибо другим не нужен. И так же чётко ассоциируется c Линуксом. Почему я тогда понял ScorpZ, а ты нет? Догадливый ты наш...

Говорить желательно по делу и/или приводить конкретные аргументы. Пока наблюдается логическая нестыковка — 100% программ из репозиториев RedHat/Debian/Slackware/Sisyphus/Ubuntu/etc. glibc алокатор вполне устраивает. Скажу даже больше — он устраивает еще 99% программ которые не входят в эти репозитории. А то что 2 программистов из этого форума он не устраивает, так это IMHO дело кривых рук этих же самых программистов — если задачу решать влоб, то тут никакой алокатор не поможет, так как дело в консерватории.

Этим 99% програм не нужна предсказуемость и прогнозируемость выполнения. Зануда абсолютно прав на счёт статического выделение или пре-аллоцирования при старте.

Если бы это было правдой, то мы бы видели их наличие в libc библиотеках by default. К счастью это не так.

Я в линуксе вообще ничего нормального не вижу по дефолту, хотя эта «нормализация» должна была появится лет 10 назад.

Відповісти

Підтримати

anonymous 09.12.2010 05:18

Выделяем X блоков (пусть будет 1024) рандомного размера

I reproduced this scenario on my Beagleboard (DM3730 @ 1GHz, number of blocks = 256, max block size = 2MB):
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.

Відповісти

Підтримати

proger 08.12.2010 21:36

Влом. ну да. вообще-то написание серверов это отдельное направление «мысли»...

Відповісти

Підтримати

anonymous 08.12.2010 21:29

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

Відповісти

Підтримати

proger 08.12.2010 21:25

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

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

Відповісти

Підтримати

anonymous 08.12.2010 20:16

Я как минимум 1 раз сталкивался с проектом, где был использован другой (отличный от glibc’шного) аллокатор. Так что видимо не всех он устраивает. А вообще, статическое выделение памяти рулит и бибикает.

Відповісти

Підтримати

anonymous 08.12.2010 19:58

Еще раз. ScorpZ ничего про ядро и не говорил. Его версию начал спрашивать ты.

Невнимательный вы наш — про версии и слова не было — ScorpZ заявил про «стандартный линуксовый алокатор», на что было замечено что Linux — это в первую очередь ядро. Или все еще грызут сомнения по этому поводу?

Смело. Обычно так говорят те, кто никогда раньше об этом даже понятия не имел.

Угм, могу сказать то же самое.

Т.е. таки ты теперь разрешаешь ScorpZ использовать другой аллокатор?:)

Говорить желательно по делу и/или приводить конкретные аргументы. Пока наблюдается логическая нестыковка — 100% программ из репозиториев RedHat/Debian/Slackware/Sisyphus/Ubuntu/etc. glibc алокатор вполне устраивает. Скажу даже больше — он устраивает еще 99% программ которые не входят в эти репозитории. А то что 2 программистов из этого форума он не устраивает, так это IMHO дело кривых рук этих же самых программистов — если задачу решать влоб, то тут никакой алокатор не поможет, так как дело в консерватории.

Дело должно быть не в IMHO, а в опыте. Многие варианты быстрее, надёжнее и лучше.

Если бы это было правдой, то мы бы видели их наличие в libc библиотеках by default. К счастью это не так.

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 08.12.2010 18:49

Еще раз — glibc аллокатор к Linux ядру имеет такое же отношение как запорожец к луноходу.

Еще раз. ScorpZ ничего про ядро и не говорил. Его версию начал спрашивать ты.

Т.е. проблема конкретизируется в «особенности работы glibc memory management» в нестандартых/кривых/не распространенных приложениях.

Смело. Обычно так говорят те, кто никогда раньше об этом даже понятия не имел.

Также можно подтюнинговать стандартный алокатор (man mallopt), использовать альтернативный или написать свой, for ex.:

Т.е. таки ты теперь разрешаешь ScorpZ использовать другой аллокатор?:)

Мое IMHO — варианты кроме glibc будут конкретно медленней и/или глючней.

Дело должно быть не в IMHO, а в опыте. Многие варианты быстрее, надёжнее и лучше.

Відповісти

Підтримати

anonymous 08.12.2010 18:31

Сталкивался с: — заканчивалось место на винтах (один из случаев — росли дампы БД) — заканчивались сроки сертификатов — падали каналы (ваша прога может быть к этому не готова) — зависали сессии, в том числе и по вине Cisco ASA (по дефолту рубал неактивные в течении 1 часа) — заканчивался срок действия пароля юзера по дефолтному профилю в Оракл 11 (6 мес.) — самопроизвольный выход из строя узлов кластера Oracle — разсинхронизация времени между узлами кластера Oracle — переход в новый год (не предусмотрели сброс счетчика нумерации документов) — накопление мусора нашим приложением в файловой системе (из 20 000 файлов полезных оказалось около 2 000) — накопление ошибки вычисления интервала запуска — ухудшение производительности из-за накопления большого количества данных — ухудшение производительности из-за увеличения количества пользователей — выключение серверов из-за перегрева — зависание сложных запросов в БД...

Відповісти

Підтримати

anonymous 08.12.2010 12:10

Еще раз — glibc аллокатор к Linux ядру имеет такое же отношение как запорожец к луноходу. Т.е. проблема конкретизируется в «особенности работы glibc memory management» в нестандартых/кривых/не распространенных приложениях.
Glibc алокатор представляет собой прекрасный компромисс между скоростью и применимостью в 99% приложений, что подтверждается неоспоримой практикой. Если же приложение написано не совсем прямо (например невзирая на фундаментальное понятие x86 архитектуры под названием PAGE_SIZE) — то и в этом случае алокатор справляется со своей задачей, правда отгрызет от heap необходимый кусок для буферирования эффекта фрагментации. Первое, что следует сделать — исправить ошибку в архитектуре приложения и ДНК разработчика. Также можно подтюнинговать стандартный алокатор (man mallopt), использовать альтернативный или написать свой, for ex.:
www.ibm.com/...brary/l-memory

Мое IMHO — варианты кроме glibc будут конкретно медленней и/или глючней.

Відповісти

Підтримати

ScorpZ Lapshov C++/C# && other programmer в AMC Bridge 08.12.2010 09:43

Под стандартным аллокатором как раз и подразумевался glib ный, вот у него с дефрагментацией туговато.

glib 2.5, ядро — 2.6.18

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 08.12.2010 06:36

Т.к. баг очень нехороший, буду Вам благодарен, если подскажете как воспроизвести эту ситуацию (какое ядро и из какого репозитария, какой аллокатор, какая версия g++ и какие библиотеки). Заранее спасибо.

Выделяем X блоков (пусть будет 1024) рандомного размера (пусть будет от 1 до 4194304, смотря сколько памяти на машине). Сохраняем указатели в массив. Затем рандомно выбираем элемент массива, релизим его и выделяем на это место новый рандомный кусок. Обязательно делать memset () для выделенного куска, либо сalloc (). Работать определённое количество времени (где-то час, если не свалится процесс раньше), после релизнуть все выделенные куски памяти и заснуть на долго. Всегда хранить количество общей выделенной памяти, её максимальное значение, чтобы затем проверять соответствие. Смотрим теперь информацию по процессу.

Відповісти

Підтримати

anonymous 08.12.2010 03:58

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

Відповісти

Підтримати

anonymous 07.12.2010 20:43

2 ScorpZ

Т.к. баг очень нехороший, буду Вам благодарен, если подскажете как воспроизвести эту ситуацию (какое ядро и из какого репозитария, какой аллокатор, какая версия g++ и какие библиотеки). Заранее спасибо.

Відповісти

Підтримати

anonymous 07.12.2010 15:48

А, уже вчитався, memset здався Маллоком

Відповісти

Підтримати

anonymous 07.12.2010 15:47

2ScorpZ
А чому delete [] p,

а не free (p)?

Відповісти

Підтримати

anonymous 07.12.2010 14:56

ну раз ясно, так курите glibc маны

Відповісти

Підтримати

anonymous 07.12.2010 14:16

ясно же, что речь о glibc

Відповісти

Підтримати

anonymous 07.12.2010 13:44

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

Выражение «стандартный линуксовый аллокатор» мне напоминает стих у Высоцкого про «любимый лунный трактор». Так как Linux — это ядро, то говоря про линуксовый аллокатор товарищ видимо имеет ввиду kernel memory management mechanism? Хочу отметить, что в отличие от других OS, в которых мысль смены аллокатора является тупо кощунственной, и люди живут с тем что есть, это ядро насчитывало на моей памяти аж 4 аллокатора (SLAB/SLUB/SLOB/SLQB), которые можно выбирать при его настройке и сборке. Kernel space аллокатор в обязательном порядке имеет в своем составе механизм дефрагментации, так как память выделяется/освобождается на загруженной машинке с огромной скоростью не только для каждого из user-space процессов, но и для нужд ядра. Это значит, что сказки о «стандартном поведении» можете рассказать Linux серверам с аптаймом в 400−600 дней — только у меня таких штук 10 наберется.
Можно побеседовать и о GC стандартной библиотеки libc, то тут нужно конкретно уточнить — о какой же именно libc пойдет речь.

Вывод: как уже было совершенно верно подмечено — нефиг на аллокатор пенять, да еще на «стандартный линуксовый ~~трактор~~»

Відповісти

Підтримати

anonymous 07.12.2010 13:06

Проблема одна — спать не дают:)

Відповісти

Підтримати

Олексій Орєшко Software engineer в Google 07.12.2010 12:39

Проблеми залежать від масштабів «програм». Ясно, що для, скажімо, «програми» масштабу гмейла навіть оновити версію ліб вже буде серйозною задачею.
Фізичні проблеми: вимкнулось живлення, проблеми у провайдера, хтось натиснув не ту кнопочку, пожежа, щось згоріло в компі.
Проблеми з софтом: великий наплив користувачів (слешдот-ефект, наприклад), необхідність оновити версію програми, оновити ліби, відновитись з бекапу, замінити сервер (и).
Специфічні проблеми: логи/бекапи займають весь вінчестер, не вистачає памяті / інших ресурсів, невчасно включився гарбадж коллектор:)
Мета-проблема: як дізнатись, що у тебе проблеми. Що і як моніторити, куди дивитись, т.п.
Мета-мета-проблема: зламався моніторинг.

Веселуха, коротше:)

Відповісти

Підтримати

ScorpZ Lapshov C++/C# && other programmer в AMC Bridge 07.12.2010 12:24

to Мурзик Васильевич

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

Відповісти

Підтримати

Oleksa Stelmakh CEO, Founder в Leobit 07.12.2010 12:22

Навіщо цю задачу дали ТОБІ якщо ти поняття не маєш як її вирішувати?
Це величезна необ’ємна область яка включає рівень Hardware, Software & Operations.

Архітектура такої аплікації описується наприклад в SaaS maturity level 4 і складається з хардварного кластерного лоадбалансера, кластерного аплікейшн сервера з реплікацією сесії і фейловером ну і звісно кластером сервера баз даних. Хоча це лише один з прикладів реалізації такої системи на софтверному і частково на хардверному рівні.

Відповісти

Підтримати

anonymous 07.12.2010 11:17

Логи могут расти быстрее чем будет работать logrotate.

Правильная настройка crond + «прямой» конфиг для logrotate спасёт отца русской демократии.:)

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 07.12.2010 11:00

Кстати, почему многие указывают логи как опасную ситуацию? Даже тупой syslogd в busybox по умолчанию ротейтит /var/log/messages, ну, а настроить logrotate — вообще дело двух минут...

Логи могут расти быстрее чем будет работать logrotate.

Эээ... Вы уверены? А что за библиотека и какая версия? Просто такая ситуация, как бы это сказать... даже не баг, это слон.:)

Это классическая ситуация в Линуксе.

Відповісти

Підтримати

anonymous 07.12.2010 10:15

Кстати, почему многие указывают логи как опасную ситуацию? Даже тупой syslogd в busybox по умолчанию ротейтит /var/log/messages, ну, а настроить logrotate — вообще дело двух минут...

P.S. Хотя да, для исследования это одна из проблем, на которую следует обратить внимание.

Відповісти

Підтримати

св Антоний 07.12.2010 09:58

100% аптайма никто не гарантирует. Но, если использовать кластер минимум из двух серверов, и вместо одного жесткого диска — RAID массив с соответствующей цифрой — то, если сбойнет или упадет одно оборудование — другое его будет дублировать. Гуглить можно по словам «кластер», «RAID»

Відповісти

Підтримати

Sergius von Bielersee 07.12.2010 09:51

— Утечки при нескольконедельной работе становятся бичом, 100 килобайт за час за 24×7 может вырасти очень заметно; — Естественно, что блуждающие баги, которые встречаются раз в неделю, за три недели 2−3 раза вылезут; — Логи переполняются.

И т.д. Первых двух достаточно, это проблема.

Відповісти

Підтримати

anonymous 07.12.2010 09:44

2 ScorpZ

Эээ... Вы уверены? А что за библиотека и какая версия? Просто такая ситуация, как бы это сказать... даже не баг, это слон.:)

Відповісти

Підтримати

anonymous 07.12.2010 09:36

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

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

Лучшие собаководы рекомендуют чтобы оно всё-таки упало.

Можно упасть его и позже и перезагрузить, главное, чтобы в критических процессах не произошел останов из — за этого, не?

Відповісти

Підтримати

ScorpZ Lapshov C++/C# && other programmer в AMC Bridge 07.12.2010 09:09

to Линуксоид
Тестили валгриндом от, а до я, никаких утечек, память после 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); // память (физическая) процесса зажралась еще на метр
//—

Поменяли аллокатор, ситуация изменилась...

Відповісти

Підтримати

anonymous 07.12.2010 09:05

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

Відповісти

Підтримати

anonymous 07.12.2010 08:49

2 ScorpZ

Valgrind вам в помощь... И нечего на линукс пенять...

Відповісти

Підтримати

ScorpZ Lapshov C++/C# && other programmer в AMC Bridge 07.12.2010 07:58

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

Так, например, прога которую мы пишем постоянно выделяет/высвобождает память. Но так, как стандартный линух-аллокатор нормально не дефрагментирует память, то со временем память процесса выростает до огромных размеров и система его килляет. Хотя в проге никаких утечек нету, просто память после free/delete реально не высвобождается, пришлось искать альтернативные аллокаторы.

Відповісти

Підтримати

anonymous 07.12.2010 07:07

Автоапдейт с авторебутом любого софта

Відповісти

Підтримати

anonymous 07.12.2010 07:02

www.computerworld.com/..._Best_practices

Відповісти

Підтримати

anonymous 07.12.2010 05:39

Лучшие собаководы рекомендуют чтобы оно всё-таки упало.

++, т.к.
можно попасть впросак, когда система «делает вид что работает».

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

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 07.12.2010 05:28

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

Вообще лимит любых ресурсов. Память, адресное пространство процесса, хэндлы, свободное место файловой системы, etc.

Остутствие обработки эксепшнов так, чтобы программа после эксепшна не валилась в кору, а восстанавливала свое состояние и продолжала работу.

Лучшие собаководы рекомендуют чтобы оно всё-таки упало.

Відповісти

Підтримати

anonymous 07.12.2010 01:11

Остутствие обработки эксепшнов так, чтобы программа после эксепшна не валилась в кору, а восстанавливала свое состояние и продолжала работу.

Відповісти

Підтримати

anonymous 07.12.2010 00:41

Counters overflow, logs rotation required, Switch to summer time

Відповісти

Підтримати

св Антоний 06.12.2010 23:22

Веерное отключение электричества, мыши, перегрызающие витую пару или уборщица со шваброй, истечение срока лицензии, сгорел винт, монитор, мамка, процессор (в смысле пожар был)

Відповісти

Підтримати

Підписатись на коментарі

Ваша пошта

Не підписуватись