Pilat: Я заметил недавно, что некоторые западные сети говорят на мой сайт "dns не найден" и Ваш хостер в этом явно не виноват, может быть и Ваши сайты с той же проблемой сталкиваются. Несколько минут 500-й ошибки это ничего.
Я бы посоветовал попробовать потестировать DNS серверы Ваших доменов, например http://demo.dnsdoctor.org/ - возможно, грубая ошибка
hpulse.ru - может проверить как резолвинг домена, так и доступность сервера/сайта, текста ответа и много чего ещё. Проверяет из одной точки.
host-tracker.ru тоже работает нормально. DNS вроде не проверяет, но работает с разных точек. Иногда показывает проблемы о доступе из разных точек.
ИМХО, первым лучше пользоваться для проверки работоспособности серверов/сервисов/сайтов, вторым - для проверки доступности сайта/сервера.
Сам пользуюсь обоими, доволен обоими (первый - мой, второй - для проверки самого себя).
Ну и в соседней консоли dd куда-нибудь. Например,
dd if=/dev/zero of=file.bin bs=8m count=100
dd if=file.bin of=/dev/null bs=8m
bs - размер блока для чтения\записи
+1 за DD,
только подождите пару минут перед второй операцией (или сделайте 'sync'), так как данные на момент чтения частично могут быть в дисковом кеше, а не на диске (по крайней мере в линуксе точно).
Ещё маленькая поправка:
dd if=/dev/zero of=file.bin bs=8192 count=100000 - по-моему, будет реальнее, если программа пишет 8-кбайтовыми блоками на диск.
Guzei: Размышления о "дёшего и сердито" увели меня от идеи сделать "зеркало" из двух SATA винтов из-за их относительной "тихоходности". Сделать зеркало на SAS - очень дорого. Вот и подумалось, а что, если:
SAS "всего" 73 гига, но 15 тыс.об./мин. для системы.
SATA на 500 гигов для резервного копирования и разного мусора.
Это жизнеспособно? Прошу критики.
Ну, если так, то 2xSCSI в raid-1, NxSATA в raid-5.
Вообще, надо исходить из требуемой скорости чтения-записи, объёмов данных (какими кусками читать-писать будете) и требуемого объёма массива.
Как уже говорил, обычный 'dd' на линуксе выдаёт 40/50 Мб/с чтение-запись на одном диске, 300/450 Мб/с на 15-ти дисковой raid-5.
Это для объёмов читаемых/записываемых данных 100-200Gb.
Для разовой записи/чтения 250Мб raid-5 выдаёт 0.6/>1 Гб/с, так как использует свой кеш.
Имейте в виду, что raid-5 теряет в надёжности с каждым новым диском. Чем больше в нём дисков - тем она меньше. А скорость больше :)
dantess: Хочу поставить на сервер еще 1 проц - такой же как уже есть - Intel Xeon 5110 1.6 GHz
Вопрос: сколько времени (min,max) сервер будет в дауне - сколько времени уйдет на установку проца. (кривизной рук при подсчете времени - принебречь 😂 )
Как это будет происходить - после установки (физической) процессора. Нужна ли будет какая-то дополнительная настройка ОС - увидит ОС 2-ой процессор?
У меня та же ситуация будет когда-нибудь, только XEON 2.8.
Расчёт времени, по максимуму, такой (ДЦ СТЕК):
- отключение сервера (кнопкой "повер", через ACPI демон): 1.5 мин.
- отключение питания, вынимание из стойки (шасси, находится внизу) и перенос в комнатку: 5 мин.
- открытие корпуса, доставание кривыми руками нового проца, сборка его: 3 мин.
- установка проца: 5 мин.
- закрытие корпуса и перенос в аппаратную: 3 мин.
- установка в стойку, подключение кабелей: 5 мин.
- загрузка ОС: 2 мин.
Получаем: 24.5 минут --> 30 минут максимум.
По ядру никаких проблем не будет, так как XEON уже видится ядром как два процессора (то есть ядро SMP). Худшее, что может случиться - это ядро не увидит его, но ОС будет работать.
Проверьте количество процессоров в настройках ядра, их должно быть 4. Я с самого начала так его собирал, но у Вас может быть по-другому.
PS. Свой сервер собирал сам, но новый проц не устанавливал и описываемых работ не производил.
PPS. Знаю, что спецов тут много, не сочтите за окончательный вариант (помидоры могу достать и из холодильника :)).
root: это приводит к выключению системы, приходится перегружать
Достаточно перезапустить mysql.
root: ничего не менялось, в логах ничего подозрительного нет, только потихоньку обновлялась база работниками, починил все таблицы, оптимизировал, все равно 0 результата,
в чем может быть проблема?
mytop поможет увидеть запросы в реальном времени.
Проблема мб в pconnect-ах или большом притоке пользователей.
root: P.S. отключаю mysqld - load averages сразу становятся 0.8-1.2
top показывает 15-25 активных процессов, около 500 sleeping
(т.к. используется pconnect)
Уберите pconnect-ы и посмотрите что изменится.
Бывает, что из-за их использования число соединений растёт. А каждое, даже спящее, соединение требует для себя выделения буферов. При sleeping соединениях скорее всего была съедена вся память и mysql ушла в своп. Из него она может и не вернуться без перезапуска (так как запросы продолжают поступать).
Как вариант, можно уменьшить количество соединений на пользователя или на всю базу вцелом. Но если проблема в pconnect-ах, то от этого она только рашьше отрубится.
Ещё вариант - написать скриптик, который будет анализировать show process list и убивать долго спящие процессы. Так сделал один мой знакомый, у него работает. Хотя можно и через my.cnf это решить.
А во фре чем-нибудь так же можно сделать?
Думаю, да. По моим наблюдениям, фря порой богаче линукса.
Dimanych, это я просто пример привёл. Не думая, что именно он сделает.:)
Вообще, это такое же правило, как и обычно.
Определяете условие для отслеживания нарушителей и вместо "-j DROP" пишете "-j LOG 'error' ".
Или вставляете LOG после всех правил об ACCEPT-ах, так определите кто и куда к вам ломится.
И лучше использовать limit в таких правилах, чтобы не зафлудился журнал :)
connlimit можно компенсировать recent - ом.
Причём более гибко. Как правило, применяется для отбрасывания брутфорсеров на SSH.
3. Отловить по логу ip, которые получают 50x и зобанить
Можно гибче :) К Вашим правилам добавить:
iptables -A FORWARD -p tcp --syn -m limit --limit 5/s -j LOG " - flooder!"
в настройках syslog-ng сделать отправку в пайп и банить сразу.
Хотя можно использовать тот же recent для этого.
Как сделать прием WM и ЯД на сайте?
условно говоря - как их принимают на sape (WM), т.е. клиент пишет сумму и у него с кошелька списывется
Merchant Webmoney - http://webmoney.ru/rus/merchants/index.shtml - читали?
Я заметил недавно, что некоторые западные сети говорят на мой сайт "dns не найден" и Ваш хостер в этом явно не виноват, может быть и Ваши сайты с той же проблемой сталкиваются. Несколько минут 500-й ошибки это ничего.
Я бы посоветовал попробовать потестировать DNS серверы Ваших доменов, например http://demo.dnsdoctor.org/ - возможно, грубая ошибка
hpulse.ru - может проверить как резолвинг домена, так и доступность сервера/сайта, текста ответа и много чего ещё. Проверяет из одной точки.
host-tracker.ru тоже работает нормально. DNS вроде не проверяет, но работает с разных точек. Иногда показывает проблемы о доступе из разных точек.
ИМХО, первым лучше пользоваться для проверки работоспособности серверов/сервисов/сайтов, вторым - для проверки доступности сайта/сервера.
Сам пользуюсь обоими, доволен обоими (первый - мой, второй - для проверки самого себя).
Аптайм считают оба.
systat -vmstat 1
Ну и в соседней консоли dd куда-нибудь. Например,
dd if=/dev/zero of=file.bin bs=8m count=100
dd if=file.bin of=/dev/null bs=8m
bs - размер блока для чтения\записи
+1 за DD,
только подождите пару минут перед второй операцией (или сделайте 'sync'), так как данные на момент чтения частично могут быть в дисковом кеше, а не на диске (по крайней мере в линуксе точно).
Ещё маленькая поправка:
dd if=/dev/zero of=file.bin bs=8192 count=100000 - по-моему, будет реальнее, если программа пишет 8-кбайтовыми блоками на диск.
Размышления о "дёшего и сердито" увели меня от идеи сделать "зеркало" из двух SATA винтов из-за их относительной "тихоходности". Сделать зеркало на SAS - очень дорого. Вот и подумалось, а что, если:
SAS "всего" 73 гига, но 15 тыс.об./мин. для системы.
SATA на 500 гигов для резервного копирования и разного мусора.
Это жизнеспособно? Прошу критики.
Ну, если так, то 2xSCSI в raid-1, NxSATA в raid-5.
Вообще, надо исходить из требуемой скорости чтения-записи, объёмов данных (какими кусками читать-писать будете) и требуемого объёма массива.
Как уже говорил, обычный 'dd' на линуксе выдаёт 40/50 Мб/с чтение-запись на одном диске, 300/450 Мб/с на 15-ти дисковой raid-5.
Это для объёмов читаемых/записываемых данных 100-200Gb.
Для разовой записи/чтения 250Мб raid-5 выдаёт 0.6/>1 Гб/с, так как использует свой кеш.
Имейте в виду, что raid-5 теряет в надёжности с каждым новым диском. Чем больше в нём дисков - тем она меньше. А скорость больше :)
Посмотрите в сторону 3ware - http://www.3ware.com/support/OS-support.asp
Как говорят, есть поддержка FreeBSD.
Использую под линуксом 7000 и 9000 серии, проблем не знал. Модули встроены в ядро. Возможно, и во фре так.
Есть утилита для ребилдинга массива "налету" - tw_cli. Вообще, много чего могут.
На raid-5 (9650SE-16ML) с 15-ю дисками у меня получилась скорость записи под 300Мб/сек.
И мне долг вернули.
А мне нет... 83 бакса так и зависли.
Всё обещали выплатить, разобраться в причинах задержки и тп, а воз и ныне там.
Видать, избирательно работают.:)
Уже не пишу им, бог с ними.
Хочу поставить на сервер еще 1 проц - такой же как уже есть - Intel Xeon 5110 1.6 GHz
Вопрос: сколько времени (min,max) сервер будет в дауне - сколько времени уйдет на установку проца. (кривизной рук при подсчете времени - принебречь 😂 )
Как это будет происходить - после установки (физической) процессора. Нужна ли будет какая-то дополнительная настройка ОС - увидит ОС 2-ой процессор?
Шасси: ASUS RS162-E4/RX4
Конфигурация: ASUS RS162-E4/RX4 MB ASUS DSBF-DR1 Intel Xeon 5110 1.6 GHz
4 Mb cashe l2 4* HDD 120 Gb Seagate Barracuda SD-RAM FB-DIMM 2Gb
Kingston DVD-ROM TOSHIBA SD-C2732
ОС: CentOS 4.4
Размер: 1U
У меня та же ситуация будет когда-нибудь, только XEON 2.8.
Расчёт времени, по максимуму, такой (ДЦ СТЕК):
- отключение сервера (кнопкой "повер", через ACPI демон): 1.5 мин.
- отключение питания, вынимание из стойки (шасси, находится внизу) и перенос в комнатку: 5 мин.
- открытие корпуса, доставание кривыми руками нового проца, сборка его: 3 мин.
- установка проца: 5 мин.
- закрытие корпуса и перенос в аппаратную: 3 мин.
- установка в стойку, подключение кабелей: 5 мин.
- загрузка ОС: 2 мин.
Получаем: 24.5 минут --> 30 минут максимум.
По ядру никаких проблем не будет, так как XEON уже видится ядром как два процессора (то есть ядро SMP). Худшее, что может случиться - это ядро не увидит его, но ОС будет работать.
Проверьте количество процессоров в настройках ядра, их должно быть 4. Я с самого начала так его собирал, но у Вас может быть по-другому.
PS. Свой сервер собирал сам, но новый проц не устанавливал и описываемых работ не производил.
PPS. Знаю, что спецов тут много, не сочтите за окончательный вариант (помидоры могу достать и из холодильника :)).
это приводит к выключению системы, приходится перегружать
Достаточно перезапустить mysql.
ничего не менялось, в логах ничего подозрительного нет, только потихоньку обновлялась база работниками, починил все таблицы, оптимизировал, все равно 0 результата,
в чем может быть проблема?
mytop поможет увидеть запросы в реальном времени.
Проблема мб в pconnect-ах или большом притоке пользователей.
P.S. отключаю mysqld - load averages сразу становятся 0.8-1.2
top показывает 15-25 активных процессов, около 500 sleeping
(т.к. используется pconnect)
Уберите pconnect-ы и посмотрите что изменится.
Бывает, что из-за их использования число соединений растёт. А каждое, даже спящее, соединение требует для себя выделения буферов. При sleeping соединениях скорее всего была съедена вся память и mysql ушла в своп. Из него она может и не вернуться без перезапуска (так как запросы продолжают поступать).
Как вариант, можно уменьшить количество соединений на пользователя или на всю базу вцелом. Но если проблема в pconnect-ах, то от этого она только рашьше отрубится.
Ещё вариант - написать скриптик, который будет анализировать show process list и убивать долго спящие процессы. Так сделал один мой знакомый, у него работает. Хотя можно и через my.cnf это решить.