из опыта работы с другими форумами, я могу предположить, что 400 юзеров - очень мало чтобы довести до 100% загрузки "север на 32гб", в предположении что там еще и все остальные комплектующие соответствующие. Скорее всего отдельные неудачные запросы все портят. Вам нужен анализ вашей конкретной ситуации и в первую очередь производительности запросов.

pachimuta грамотно сконфигурировать MySQL где сервер имеет 32Gb RAM
Да никак. "Грамотность" в IT - оправдание для шаблонности мышления. Все, что удовлетворяет вашим запросам - грамотно.

pachimutaМожно ли организовать основную работу базы в памяти, раз она вся туда помещается, а на диск делать только операции записи?
А то. Но это типа "неграмотно", ведь данные пропадают при перезагрузке. С другой стороны, шаблоны экономят время и предостерегают от совсем уж неправильных решений.

miksoftnetwind400 юзеров - очень мало чтобы довести до 100% загрузки "север на 32гб"Зависит от терминологии и неявно подразумевающегося смысла (который у всех разный).
Если это 400 юзеров, которые в браузере смотрят на страничку сайта - это, действительно, не так много.
экслуатанты коробочных форумов понимают это почти что однозначно. Там существует таблица сессий, записи из которой удаляются по истечении 15 минут неактивности.

MasterZivДо 100% загрузки CPU и один запрос может довести. И это кстати хорошо.
Кстати, нет. Mysql не умеет обрабатывать один запрос на нескольких ядрах. Наверняка многоядерный процессор имеется.

miksoftpachimutaДвижок myISAMТогда ответ частично отрицательный. MyISAM не имеет общего кэша таблиц, но имеет кэш индексов. Потенциально, файлы таблиц могут кэшироваться на уровне кэша файловой системы, но тут я не уверен.
Совершенно точно данные myisam кешируются на уровне ОС.
Кроме того, при использовании myisam_use_mmap=1 еще и экономятся системные вызовы на чтение файлов. Хотя зачастую эта настройка дает лишь небольшой прирост.
Плохо то, что при совместной работе mysql и веба, какие-то проблемы на вебе или бекапы этот самый кеш "смывают". С innodb такого не происходит. И даже несмотря на все это, myisam намного проще и зачастую производительность в вебе все равно лучше innodb.

Теперь о картинке.
htop - отстой. Из всех программ вы выбрали самую бесполезную, но цветастую. По картинке нельзя оценить ни показатель iowait, ни долю user cpu в нагрузке на процессор.
Используйте обычный top, два раза выше упомянутую программу pt-summary (она снимает то же самое за 10 секунд) или atop, который еще и логи пишет весьма интересные и позволяющие "промотать" картинку назад во времени.
Тем не менее, можно предположить, что самым важным для вас должен стать анализ медленных запросов.
Если нет длиннее 2 секунд, то уменьшите таймаут и снова проанализируйте.


Еще видно, что mysql весьма мало памяти использует. Это значит что можно увеличить key_buffer_size. Попробуйте также советы от программы mysqltuner, но сильно не увлекайтесь. Используйте ее только для оценки key_buffer_size.

pachimutaРазрабатывая текущий проект, задался вопросами:
1. почему же до сих пор нет решения для построения распределенной базы данных с некритической к постоянному соединению системой синхронизации/репликации данных

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

2. это ведь довольно просто должно быть написать движок, который бы считывал из таблиц данные и индексы, оперировал бы ими полностью в оперативке, а на винт записывались бы только изменения. Скорость базы возросла бы на порядок, я так понимаю?
Вы не поверите, но во всех субд при наличии кеширования файлов на диск пишутся только изменения.