Замедлите NFS и производительность GFS2
Я использовал ffmpeg в течение долгого времени и в различных целях кодирования/декодирования. Я нахожу это очень надежным. MPlayer, Mencoder и VLC являются хорошими плеерами, которые основаны на ffmpeg библиотеке, таким образом, Вы могли использовать их для более легкого синтаксиса и расширили функциональность.
И примечание стороны: VLC не является только великим игроком, но также и чрезвычайно мощным сервером потоковых медиа. Используя VLC можно также транскодировать, сжать/распаковать различные файлы и форматы.
I can only provide some general pointers.
First I would get some simple benchmark metrics up and running. At least then you'll know if the changes your making are for the best.
- Munin
- Cacti
Nagios
are some good choices.
Are these nodes virtual or physical servers, what's their spec.
What kind of network connection are between each node
Is NFS setup over your hosting providers private network.
Your not limiting packets / ports with firewalls, Is your hosting provider doing this?
First HA proxy front the web servers with either Varnish or Nginx.
Then for web file system: Why not use MooseFS instead of NFS, GFS2, its fault tolerant and fast for reads. What you loose from NFS, GFS2 is local locks, do you need that for your application? If not I would switch to MooseFS and skip the NFS,GFS2 problems. You will need to use Ucarp to HA the MFS metadata servers.
In MFS set replication goal to 3
# mfssetgoal 3 /folder
//Christian
Думаю, у вас две проблемы. Узкое место, вызывающее проблему, и, что более важно, плохая обработка сбоев GFS. GFS действительно должна замедлять передачу, пока она не заработает, но я не могу с этим помочь.
Вы говорите, что кластер обрабатывает ~ 200 ГБ новых файлов в NFS. Сколько данных считывается из кластера?
Я всегда нервничал, имея одно сетевое соединение для интерфейса и серверной части, поскольку это позволяет веб-интерфейсу «напрямую» нарушать работу серверной части (путем перегрузки соединения для передачи данных).
Если вы установите iperf на каждый из серверов, вы можете проверить доступную пропускную способность сети в любой точке. Это может быть быстрый способ определить, есть ли у вас узкое место в сети.
Насколько интенсивно загружена сеть? Насколько быстры диски на сервере хранения и какую настройку рейда вы используете? Какая у вас пропускная способность? Предполагая, что он работает под управлением * nix и у вас есть время для тестирования, вы можете использовать hdparm
$ hdpard -tT /dev/<device>
. Если вы обнаружите, что сеть сильно загружена, я бы посоветовал установить GFS на вторичное и выделенное сетевое соединение.
В зависимости от того, как вы выполняете рейд. (ред) 12 дисков, у вас может быть разная производительность, и это может быть вторым узким местом. Это также будет зависеть от того, используете ли вы аппаратный рейд или программный рейд.
Обильные объемы памяти, которые у вас есть на коробке, могут быть мало полезны, если запрашиваемые данные распределены по большему объему, чем ваша общая память, которую он звучит так, как могло бы быть. Кроме, память может помочь только с чтениями, и это тоже в большинстве случаев, если много чтений относится к одному и тому же файлу (иначе он был бы удален из кеша)
При запуске top / htop наблюдайте за iowait. Высокое значение здесь является отличным индикатором того, что процессор просто вертит пальцами в ожидании чего-то (сеть, диск и т. Д.)
На мой взгляд, NFS с меньшей вероятностью может быть виновником. У нас довольно большой опыт работы с NFS, и хотя он может быть настроен / оптимизирован, он имеет тенденцию работать довольно надежно.
Я был бы склонен стабилизировать компонент GFS, а затем посмотреть, исчезнут ли проблемы с NFS.
Наконец, OCFS2 может быть вариантом, который можно рассмотреть как замену GFS. Пока я проводил некоторое исследование распределенных файловых систем, я провел достаточно много исследований и не могу вспомнить причины, по которым я решил попробовать OCFS2, но я это сделал. Возможно, это как-то связано с тем, что Oracle использует OCFS2 для своих баз данных, что подразумевает довольно высокие требования к стабильности.
Мунин - ваш друг. Но гораздо важнее top / htop. vmstat также может дать вам несколько ключевых чисел
$ vmstat 1
, и вы будете получать каждую секунду обновление о том, на что именно система тратит свое время.
Удачи!
На основании ваших графиков munin система отбрасывает кеши, это эквивалентно выполнению одного из следующих действий:
echo 2> / proc / sys / vm / drop_caches- free dentries и inodes
echo 3> / proc / sys / vm / drop_caches- free pagescache, dentires и inodes
Возникает вопрос: почему, возможно, существует затяжная задача cron?
За исключением 01:00 -> 12:00, они кажутся регулярными.
Также стоит проверить примерно половину пика, если выполнение одной из вышеперечисленных команд воссоздает вашу проблему, однако всегда убедитесь, что вы запускаете sync прямо перед этим.
Если strace вашего процесса drbd (опять же, предполагая, что это является виновником) время ожидаемой продувки и до указанной продувки может пролить некоторый свет.