- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Собственно если не munin, я бы наверное об этом и не знал, но
Он даёт график по которому по оранжевой секции много TIME_WAIT
По переводу так wait - уже что-то не хорошее (((
Вообще хотелось бы узнать что значат все эти разделы:
Established
FIN_WAIT
TIME_WAIT
SYN_SENT
UPD Connection
Assured
NATed
На сколько я понял, толкования графиков Munin`а на русском нет вообще, а на не русском мне пока сложно понять. Разобраться хотя бы с этим :(
OpenVZ - Ngix+LAMP
worker_processes 2; (но ядро одно, стало быть нужно одиничку поставить..)
worker_connections 2048; (видимо нужно по мене 1024 или нет)
только что поменял
keepalive_timeout 5; (вместо 65 но ситуацию не поменяло)
Остального не трогал, осталось по дефолту от ISPmanager
оперативки и процессора относительно много, сайт работает нормально. имхо дело только в конфигах
полностью понимаю что ничего не понимаю, было бы хотя бы за что зацепиться..
"По переводу так wait - уже что-то не хорошее ((("
=)
"Стоит ли паниковать из-за TIME_WAIT"
не стоит, стоит хотя бы приложить усилия что бы иметь представление о состояниях TCP протокола и не задовать глупых вопросов.
"worker_processes 2; (но ядро одно, стало быть нужно одиничку поставить..)"
настраивать нужно из расчета нагрузки и конфига сервера а не тупо по количеству ядер.
"keepalive_timeout 5; (вместо 65 но ситуацию не поменяло)"
чем дефолтный не угодил, что то где то вычитали?
"оперативки и процессора относительно много, сайт работает нормально"
как говорится, работает - не трогай.
чем дефолтный не угодил, что то где то вычитали?
именно, вычитал что некоторые 0 ставят, но я не такой рисковый. поставлю обратно, раз эффекта не возымело..
как говорится, работает - не трогай.
ну я так, в качестве повышения образованности ))
---------- Добавлено 08.12.2012 в 21:39 ----------
о состояниях TCP протокола
Ну вот она, точка опоры )) спасибо
так уже понятнее немного )) http://book.itep.ru/4/44/tcp_443.htm - хотя ацки много букаф, буду асиливать..
А вот и Википедия
Состояния сеанса TCP
CLOSED Начальное состояние узла. Фактически фиктивное
LISTEN Сервер ожидает запросов установления соединения от клиента
SYN-SENT Клиент отправил запрос серверу на установление соединения и ожидает ответа
SYN-RECEIVED Сервер получил запрос на соединение, отправил ответный запрос и ожидает подтверждения
ESTABLISHED Соединение установлено, идёт передача данных
FIN-WAIT-1 Одна из сторон (назовём её узел-1) завершает соединение, отправив сегмент с флагом FIN
CLOSE-WAIT Другая сторона (узел-2) переходит в это состояние, отправив, в свою очередь сегмент ACK и продолжает одностороннюю передачу
FIN-WAIT-2 Узел-1 получает ACK, продолжает чтение и ждёт получения сегмента с флагом FIN
LAST-ACK Узел-2 заканчивает передачу и отправляет сегмент с флагом FIN
TIME-WAIT Узел-1 получил сегмент с флагом FIN, отправил сегмент с флагом ACK и ждёт 2*MSL секунд, перед окончательным закрытием соединения
CLOSING Обе стороны инициировали закрытие соединения одновременно: после отправки сегмента с флагом FIN узел-1 также получает сегмент FIN, отправляет ACK и находится в ожидании сегмента ACK (подтверждения на свой запрос о разъединении)
именно, вычитал что некоторые 0 ставят, но я не такой рисковый. поставлю обратно, раз эффекта не возымело..
ну пусть они ставят 0, только потом будут удивляться в том что сайт их супер сайт медленно открывается, а вы прежде чем что то крутить читайте доку и думайте надо ли оно вам.
0 иногда имеет смысл поставить в apache если перед ним nginx.
Den73,
И вы таки думаете что я из этого что-то понял? Да пусть я трижды всё перечитаю мне этого мозгом не асилить :(
именно, вычитал что некоторые 0 ставят ... эффекта ...
Можно задать вам простой вопрос: зачем вы изменили настройку и какого эффекта хотели добиться?
И вы таки думаете что я из этого что-то понял? Да пусть я трижды всё перечитаю мне этого мозгом не асилить :(
Ну и почему кто-то знающий должен тратить время на метание бисера перед вами? Задумаейтесь.
А как же альтруизм?
Ну его же тут не гоняли грязными тряпками. Вот в этом и заключен альтруизм.
Более того, вполне конкретно ткнули в то, что читать.
Ну его же тут не гоняли грязными тряпками. Вот в этом и заключен альтруизм.
Ну и почему кто-то знающий должен тратить время на метание бисера перед вами? Задумаейтесь.
Пока меня нет вы мне тут все косточки поперемывали (((
Бисер мне особо не нужен, я просто поинтересовался у знающих на случай если есть какое-то простое решение. А носом меня ткнули только в
Вас "носом ткнули" - в совершенно другое, посоветовали читать...
"Простое объяснение" дать сложно по той простой причине, что телепатов тут нет. В зависимости от ваших проектов - такая ситуация может быть и нормальной, и нет.