Как определить сбой сетевого подключения?
Для обсуждения того, как рассчитываются средние значения нагрузки, посмотрите несколько устаревшую (но все еще полезную) статью --
http://www.linuxjournal.com/article/9001?page=0,1
Исходя из ваших данных, поскольку ваша нагрузка составляет ~ 24 - 32, а у вас 4 ядра, средняя нагрузка на ядро составляет ~ 6 - 8 (процессы, ожидающие CPU). Поскольку загрузка процессора низкая (69% простоя), можно сделать вывод, что у вас большое количество потоков, ожидающих завершения ввода/вывода (расчет load avg включает потоки, ожидающие завершения ввода/вывода). Высокий % ожидания (~30) также указывает на то же самое. Есть 2 вещи, которые вы можете сделать - 1. запустить iostat на дисках, чтобы посмотреть подробную статистику времени ожидания на каждом диске. 2. запустите ps и проверьте наличие 'D' в статусе, чтобы увидеть потоки, ожидающие завершения ввода-вывода. Следующим шагом к решению вышеупомянутых проблем (в зависимости от того, где находится проблема) может быть приобретение более качественных и быстрых дисков или более тщательное изучение путей ввода-вывода в вашем коде. Вы можете использовать другие инструменты, такие как perf, чтобы получить еще более глубокое представление о том, откуда именно берется время ожидания приложения.
Вы пытаетесь добавить ошибку Windows в Linux. Linux не имеет этой ошибки специально.
Я называю это недоработкой, потому что когда Windows делает это, она уничтожает все соединения, использующие этот сетевой интерфейс, даже если ни один пакет не был потерян. Кроме того, если у вас не самый простой случай, когда есть только две машины и перекрестный кабель (или MDI-X), он не может обнаружить сбои в промежуточных или удаленных частях соединения физического уровня.
Подумайте об этом: Windows разрывает соединения только при обнаружении локального сбоя, который вполне может быть временным, но даже не пытается обнаружить сбои на более отдаленных участках.
Windows может надеяться, что эти посредники и ее удаленные коллеги скопируют ее ошибку, но они этого не сделают, потому что они разработаны по тем же принципам, что и протоколы самого Интернета, который был разработан с учетом сбоев. Весь Интернет не взрывается, когда основной маршрутизатор дает небольшой сбой. Он справляется.
Если вам интересно, чем я руководствуюсь, придерживаясь такого твердого мнения, то это тем, что я пишу сетевые программы уже около двух десятилетий. Этот опыт вбивает в вас закон Мерфи: все, что может пойти не так, пойдет. Опускание рук при каждой маленькой неудаче только делает ваши программы хрупкими. Лучше справляться.
Вы когда-нибудь замечали, что ваш веб-браузер не закрывает все свои вкладки при обрыве сетевого соединения? Это потому, что он справляется с сетевыми сбоями. Отчасти это связано с конструкцией HTTP, но отчасти - с выбором разработчиков веб-браузера для работы с обнаруживаемыми сбоями. В отличие от этого, проводник Windows отбрасывает все открытые окна проводника в папку по умолчанию (Мой компьютер, обычно), поэтому, когда вы возвращаетесь на машину после сбоя, вы теряете свое рабочее место.
Если вам совершенно необходимо сделать это, то инструменты, предложенные в ответе robbat2, сделают это. Однако гораздо лучше написать свои сетевые программы, чтобы справиться с отказом сетевого соединения.
Когда отказ не является вариантом, установите резервные сетевые интерфейсы, используя функцию NIC channel bonding ядра Linux. Вы можете настроить систему на автоматическое переключение на второй (или третий!) сетевой интерфейс при отказе одного канала.
Установите netplug, ifplugd или аналогичный пакет в ваш дистрибутив; они могут циклически менять адреса ваших интерфейсов на основе физического состояния соединения.