Загрузка ЦП является низкой, но выгрузила процессы и заблокировалась, процессы высоко
Не ясно точно, что Вы подразумеваете под "выравниванием нагрузки" в этом контексте.
Если Вы хотите использовать и порты Ethernet для соединения с тем же переключателем для получения более высокой пропускной способности (2 Гбит/с) и также корректно ухудшиться к 1 Гбит/с, если любой кабель становится отключенным, то необходимо настроить 802.3ad агрегирование каналов.
802.3ad понятие сети уровня 2, что означает, что это происходит перед предоставлением IP-адреса сетевому интерфейсу. При создании агрегирования каналов Вы получите новый "виртуальный" интерфейс, которому можно присвоить IP-адрес.
Вы должны иметь переключатель, который поддерживает это, и необходимо настроить порты коммутатора как таковые.
См. также описание на странице Mac OS X Server Networking Apple.
У ваших виртуальных машин такое же количество процессоров, что и в хост-системе? в таком случае это плохо и может помешать правильной работе планировщика. IE, если у вас 8-ядерная система, тогда ни одной системе на этом компьютере не должно быть назначено 8 ядер. У вас может быть 20 виртуальных машин с 4 назначенными ядрами, и это не проблема, но 1 ящик с 8 назначенными ядрами может вызвать проблемы под нагрузкой.
At first sight, your system had a severe RAM shortage in the past. The average scan rate since last boot is 117 while it should 0 or close to it on a system with enough RAM. This seems to be confirmed by your 31 w column which likely means 31 daemons were swapped out during the ram shortage event and never came back being unused.
Испытываете ли вы 100% загрузку всех 32 ядер ЦП или только некоторых? Я не могу говорить о статистике, которую вы опубликовали, поскольку она довольно нечитабельна, но чтобы попытаться дать некоторые общие ответы на вещи, с которыми вы сталкиваетесь:
Заблокированные / замененные процессы Иногда процессы в серверной ОС привязываются к определенному ядру ЦП и ТОЛЬКО используют это ядро для своих нужд, игнорируя все остальные ядра. Как правило, это больше проблема для старых программ, которые не были предназначены для работы в многоядерных системах. Конечным результатом является то, что если у вас есть несколько процессов, которые делают это, и они решили использовать одно и то же ядро, они будут постоянно блокировать и менять местами друг друга, чтобы делать то, что им нужно делать, в то время как другие ядра простаивают, ничего не делая. Иногда вы можете настроить программное обеспечение для выбора конкретных ядер и вручную «балансировать» процессы между вашими процессорами (аналогично ручной настройке IRQ в те времена), но это, очевидно, нежелательно, поскольку требует ручной перенастройки с вашей стороны и вас. может в конечном итоге ухудшить ситуацию. Выясните, какие процессы блокируют друг друга, и сосредоточьтесь на них. Я сомневаюсь, что у вас есть узкое место в процессоре с 32 ядрами, но я также не могу сказать наверняка. Прочтите документацию по процессам / программному обеспечению, чтобы узнать, что рекомендует производитель, и можете ли вы даже настроить процесс для этого.
Заблокированные / замененные процессы выше, чем запущенные процессы Вероятно, что происходит, так это то, что ваш счетчик производительности просто тикает каждый раз, когда процесс блокируется / выгружается, и не показывает ТЕКУЩИЕ заблокированные / замененные процессы, поэтому он всегда должен быть выше, чем ваши запущенные процессы (это именно то, что он говорит - количество запущенных в настоящее время процессов в вашей системе). Это не должно вызывать беспокойства.
Do you have any automated backup processes or something which would be thrashing the disk(s)? It sounds vaguely like you've got IOwait issues. Can you get a snapshot of mpstat while your server's unhappy? You could probably rule out the disk i/o issue by doing small 5GB writes to disk or something in DIRECT_IO mode (to get around the fact you could cache half the earth in free memory on that sever). Also, have you tried (if you're able) examining your queries during this time? Maybe someone's slamming you with a bunch of full-index scans or something?