- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день. Нужен хороший специалист по FreeBSd.
Сначала суть проблемы:
Проблемы у меня такие: Есть выделенный арендованный сервак и на нем стоит FreeBSd 6.1. Периодически зависает. На консоль не реагирует.
Для перезагрузки помогает только кнопка Reset. Полтора месяца назад увеличил память РАМ на серваке (было 1 гигабайт, теперь стало 2 гигабайта). Не
знаю, совпадение или нет, но после увеличения памяти стала зависать
система гораздо чаще. Сперва 1 раз в 2 недели, а последнее время где-то пару раз в неделю.
Вот тут нашел высказывание про FreeBSd и память: http://dedic.ru/node/247
Чтобы мне хотелось:
1. Найти и устранить причину зависаний.
2. Нужно обновить FreeBSd 6.1 до версии FreeBSd 6.2 Stable (стабильная версия).
Возможно и причины зависаний исчезнут, в FreeBSd 6.2, как пофиксены многие баги,
доработанное ядро, введен какой-то аудит ядра, по заявления разработчиков - она
стабильнее. Я прав или нет?
3. Вот тут прочитал про Kernel Panic - не паниковать! http://dedic.ru/node/92
Очевидно надо эту штуку сделать и для версии FreeBSd 6.2. Чтобы в случае чего,
FreeBSd не висла, а перезагружалась. Есть в этом смысл, как вы считаете?
На железо не грешу. Тут вроде как все нормально. Несколько дней назад железо
полностью заменили в дата-центре. Вынули диски с одного сервака и переставили в
другой новый, аналогичный по конфигурации. Проработало 4 дня и один хрен зависла.
Пришлось перезагружать.
При загрузке системы выдало ошибки кстати. Такие:
server.izcity.com kernel log messages:
+++ /tmp/security.UuLtMtsu Fri Nov 2 03:02:08 2007
+CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz 686-class CPU)
+WARNING: / was not properly dismounted
+WARNING: /tmp was not properly dismounted
+WARNING: /usr was not properly dismounted
+/usr: mount pending error: blocks 80 files 0
+WARNING: /var was not properly dismounted
+pid 31617 (httpd), uid 80: exited on signal 11
Правда, все работает пока. На серваке лежит лог загрузки полностью. Можно
посмотреть.
/var/log/messages
Еще дополнительный вопрос: может ли быть причиной зависаний какие-то ошибки в работе
Apache 2, Php, MySql, Sendmail? Тут бывают проскакивают ошибки разные, в логи
пишутся. Это может быть причиной зависания системы? Или дело все-таки в системе?
В общем такая проблема с FreeBSd 6.1. Нужно решать ее. Что скажете?
Подытоживаю:
1. У кого-какие соображения по поводу причин возникновения сей проблемы?
2. Нужен удаленный админ-специалист (платно) для разруливания этой ситуации
разрулил ситуацию ?
Imho железо. Стресс тесты после установки модулей памяти какие-нибудь запускали?
Попросите саппорт переслать вам сообщение, показанное на системной консоли при зависании. И, между делом, выставьте переменную ядра kern.sync_on_panic в единицу.
у меня память глючила , причем тесты не показывали ничего - пару раз тестили.
проверили третий раз - битая память - всетаки была.
поговорил с датацентром с моим - кивают типа - бывает такая , что сдыхает не во время теста,а после :-)
Стрессы железа оставьте на совести хостера :-)
там элементарно может быть битым шлейф на винт ( да да и такое видел)
как вариант можно попробовать простой вариант - тормознуть все сервиса "пользовательские" что сюрпризов не было и сделать две вещи - протестить читабельность всего винта, и подергать оперативу - просто заполняя ее на 99 процентов и освобождая.
ну и чисто с своего опыта (на что я налетал):
могу посоветовать посмотреть потребление оперативы.
занять Всю оперативу и своп - дело долей секунды. особенно на хорошем канале
отрезать лишнее на интерфейсе фаерволом.
пересобрать ядрышко с пулингом.
и смотреть софт. как вариант - ну обновить по мере возможности.
61 фряха в общем то не так уж и плохо работает - у меня по году аптайма на раздаче - рас=здаю апачем в пару сотен потоков. на 10мегабитном канале 3Т. больше просто не пролазит в эзернете
хотя в 99 процентах случаев когда занята вся оператива и Весь своп - Пинги кернел еще воспринимает. а остальное уже "выпадает" к этому моменту
есть еще вариант - отрубается винт
тогда в логах будет чисто
соответственно сливать логи на другую тачку с сислога
чтобы видно было что там творится
А у Вас KVM есть ?
Можем обновить систему, проверить железо .
Добрый день. Спасибо всем за комментарии.
Мой общий ответ:
1. Тесты памяти естественно никто не тестировал :)
2. Сообщения с системной консоли, суппорт не высылал. Но спасибо за совет, если что - то буду требовать на будущее. Ранее во время одного из зависаний суппорт на словах говорил что-то про SYSERR и почтовую систему. Предполагаю там было что-то типа такого:
Nov 13 08:50:50 server sm-mta[33725]: lAD4onOd033725: SYSERR(root): collect: read timeout on connection from 70-58-194-213.ptld.qwest.net, from=<tadahiro36twila@barco.com>
Ну собствено и в логах на момент зависания (и последующей перезагрузки) было то же самое...
Т.е. записи Сендмейла. Ну так он такое каждый день пишет. Тут просто кто-то шлет спам и не дожидаясь ответа почтового сервака, отключается. На мой взгляд - обычная рабочая ситуация.
3. Переменную ядра kern.sync_on_panic выставить в единицу. Э... пока не трогал этот момент (сам не разбираюсь в этом). Ну вообще в логах нигде нет упоминания про Kernel Panic. Хотя совет конечно здравый.
4. Памяти на системе стоит 2 гига, проблемы с нехваткой отпадают. Ниже команда ТОР.
last pid: 47887; load averages: 0.28, 0.26, 0.24 up 10+10:25:31 12:19:41
252 processes: 1 running, 250 sleeping, 1 zombie
Mem: 639M Active, 945M Inact, 247M Wired, 104M Cache, 112M Buf, 60M Free
Swap: 4055M Total, 228K Used, 4054M Free
5. Сейчас такое впечатление, что ситуация вроде как устаканилась, тьфу-тьфу :) Предполагаю, что возможно была MySQL виновата. Увеличил выделение памяти для всех операций с MySQL, сейчас она кушает 500 мегабайт памяти (сервак хорошо посещаемый в смысле посетителей). И 1,5 гига памяти осталось на все остальное.
Возможно цепочка была такая: Тормозилась MySQL в какие-то моменты, а за ней автоматом почему-то подвисала и FreeBSD.
Либо второй вариант: MySQL тут ни при чем, а неуверенно работала сама FreeBSD на 2 гигах памяти. Много это для нее... Потому как ранее, когда на серваке был 1 гигабайт памяти, FreeBSD работала стабильнее. Рекорд - полгода без зависаний и падений. Ну это собствено насчет памяти - только мои предположения...
6. В обшем сейчас пока стабильно все работает (тьфу-тьфу...). Пока ничего не трогаю и никаких телодвижений не совершаю...
7. Да, KVM можно получить в дата-центре на нужное время. Если что, то я буду иметь ваше предложение ввиду, remsys.
На мой взгляд - обычная рабочая ситуация.
Так и есть. К зависанию отношения не имеет.
Ну вообще в логах нигде нет упоминания про Kernel Panic.
В логах его и не увидите.
last|grep crash
last|grep crash
Это что есть такое? В смысле - мне непонятна эта запись
Это что есть такое? В смысле - мне непонятна эта запись
это надо набрать в консоле