PrAw

Я бы предложил пойти от обратного
https://docs.microsoft.com/en-us/sysinternals/down...
https://habr.com/ru/post/466941/
посмотреть чем проводник занят и отключить прицельно.

Довольно часто помогает отключить просмотр thumbnails.

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

https://mva.microsoft.com/
Помнится здесь я встречал лабораторные с подключением к облаку микрософта. Могу ошибаться, возможно это был платный курс, временно выложенный фри.

Ну а по большей части для большинства простых топологий тебе хватит обычного компа на 8 гиг оперативки и фришного Virtual Box. Потребуется много терпения, но работать будет.

Если очень хочется - то по студенческому или просто нахаляву на Azure, Amazon есть немного бесплатных ресурсов, которые можно задействовать для экспериментов.

А лучше всего скиллы поднимает эникейство в местечковой (это важно!) госструктуре. Это:

• археологические изыскания в слоях Win98-Win10
  
• практика с Windows Server 2000-2016
  
• разнообразные пользователи
  
• тренажер тееррпеениияя
  
• тренировка смекалки, как сейчас и без денег решить задачу
  
• планирование, ибо бюджетные деньги надо закладывать заранее
  

Моя личная история - при любом вопросе ответить "сейчас разберемся и попробуем сделать"

В любом случае придётся собирать стенд из нескольких источников/приемников трафика. Это может быть как микротик, так и комп. Еще у циски есть IP SLA, но всё-равно то больше тест прикладного уровня, не канального.

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

Лимит маков можно проверить с помощью scapy. Потребуется некоторое знание программирования на питоне. Генерите в цикле случайные исходящие маки, флудите ими, а параллельно шлём пинги. Еще один участник просто сидит и слушает. Когда он тоже начинает слышать пинги - таблица маков переполнилась и наш свитч стал хабом :).

Значит, что у тебя файловые операции почти упираются в потолок по пропускной способности носителя. Если всё нравится, то недельку можно не переживать.

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

Если БД виновата, можно попробовать перекинуть её на отдельный сервер или сделать master-slave репликацию, тогда master будет грузиться в основном на запись, а slave больше на чтение. Но это имеет смысл, если у тебя чтений сильно больше, чем записей.

Могут быть виноваты:
1. Методика тестирования - тестировался совсем пустой index.php или что-то более сложное?
2. Результаты TOP/IOTOP было бы интересно увидеть, вполне возможно, что тестировалась скорость жесткого диска или перегруженность процессора в случае оверселлинга

с виду характеристик сервера хватает, а на деле может быть проблема была в коннекте к mysql

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

MS Server Core редакции немного страшноваты в настройке, там повершелл будет полезен.
Автоматизация некоторых операций в Active Directory тоже делается заметно легче с повершелл.

Обработать логи - bash, grep, sed, awk в сумме рулят заметно больше простотой команд (или мне больше нравится).

Автоматизировать инсталлятор или какие-то оконные манипуляции - проще получается задействовать AutoIT, чем лезть в потроха и находить другие методы взаимодействия.

Единого и удобного инструмента нет, так что хватайте всё и работайте.

Подключи этот модуль:
https://httpd.apache.org/docs/current/mod/mod_stat...
покажет чем занят каждый воркер, там уже сможешь более прицельно искать виновника.

Второй вариант, настроить лог
httpd.apache.org/docs/2.2/mod/mod_log_config.html
Там есть замечательный параметр:
%T The time taken to serve the request, in seconds.
Тоже даст список подозреваемых.

Даже просто поиск по всем файлам по "eval(" в случае php даст тебе список всех подозрительных файлов. Но в любом случае пока дырка всё еще есть, то повторное заражение не за горами, надо искать причины.

По основному вопросу - вести текстовый лог из скрипта.
В идеале сначала разобраться, почему падает, а потом уже городить велосипед. Скорей всего или дело в неответе чего-то удаленного или исключительная ситуация. В случае с php можно ведь вести и лог ошибок
php.net/manual/ru/function.error-log.php
в конкретно взятых скриптах прописать - куда им признаваться в своих ошибках.

По дополнительному вопросу - fail2ban
настройки по умолчанию уже содержат автобан на небольшой промежуток времени активным подбирателям.