Host.Community | hcom.link

Здравствуйте.

Имею следующий конфиг:

2 x IBM x3630, по 14 2Tb SATA-дисков в каждом, на каждом собран raid10 из 12 дисков, 2 в hot-spare.

Гигабитный линк между серверами.

DRBD поверх устройств raid10 (md-raid).

Производительность /dev/md127:

throughput ~ 900 MB/s

fio со следующим конфигом:
Конфиг fio[readtest] blocksize=4k filename=/dev/md/raid10 rw=randread direct=1 buffered=0 ioengine=libaio iodepth=16

выдает примерно такие цифры:
Вывод fioreadtest: (groupid=0, jobs=1): err= 0: pid=5009 read: io=38632KB, bw=3502.5KB/s, iops=875, runt= 11030msec slat (usec): min=4, max=135, avg=15.63, stdev= 4.91 clat (msec): min=1, max=149, avg=18.19, stdev=12.39 lat (msec): min=2, max=149, avg=18.21, stdev=12.39 bw (KB/s): min= 0, max= 3736, per=61.09%, avg=2139.33, stdev=1733.77 cpu: usr=1.16%, sys=2.03%, ctx=9085, majf=0, minf=36 IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.8%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0% issued r/w/d: total=9658/0/0, short=0/0/0 lat (msec): 2=0.01%, 4=0.38%, 10=21.22%, 20=49.09%, 50=26.52% lat (msec): 100=2.63%, 250=0.16%

875 иопсов при задержке в 18 мс. Меня устраивают такие цифры, всё хорошо.

fio на запись — аналогично.
Конфиг fio[writetest] blocksize=4k filename=/dev/md/raid10 rw=randwrite direct=1 buffered=0 ioengine=libaio iodepth=16

Вывод fiowritetest: (groupid=0, jobs=1): err= 0: pid=5023 write: io=169624KB, bw=3912.7KB/s, iops=978, runt= 43353msec slat (usec): min=2, max=20841, avg=10.85, stdev=101.29 clat (usec): min=15, max=169027, avg=16321.19, stdev=33566.14 lat (usec): min=267, max=169040, avg=16332.46, stdev=33566.13 bw (KB/s): min= 2936, max= 7334, per=100.26%, avg=3922.26, stdev=526.96 cpu: usr=1.02%, sys=1.50%, ctx=40727, majf=0, minf=18 IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0% issued r/w/d: total=0/42406/0, short=0/0/0 lat (usec): 20=0.01%, 250=0.01%, 500=33.40%, 750=9.47%, 1000=5.28% lat (msec): 2=18.85%, 4=13.12%, 10=1.09%, 20=0.87%, 50=1.70% lat (msec): 100=12.06%, 250=4.15%

978 iops при задержке до 17 мс. Тоже прекрасно.

Далее начинается самое интересное.

Создаю drbd-устройство со следующим конфигом:
resource r0 { device /dev/drbd0; disk /dev/md/raid10; meta-disk internal; on storage00 { address 192.168.254.10:7789; } on storage01 { address 192.168.254.11:7789; } net { max-buffers 8000; max-epoch-size 8000; } }

И получаю нечто, не поддающееся обработке разумом, а именно:

Throughput на чтение почти не деградирует (чего и следовало ожидать, чтение идёт с локальной ноды).

Throughput на запись фиксируется ровно на 60 МБ/с. Маловато, от гигабита я ожидал 110 МБ/с, тем более, что initial sync drbd-устройства происходил как раз на скорости 110 МБ/с.

Снова fio при StandAlone-устройстве. Чтение:
Конфиг fio[readtest] blocksize=4k filename=/dev/drbd0 rw=randread direct=1 buffered=0 ioengine=libaio iodepth=16

Вывод fioreadtest: (groupid=0, jobs=1): err= 0: pid=5214 read: io=154380KB, bw=3500.5KB/s, iops=875, runt= 44103msec slat (usec): min=5, max=417, avg=17.87, stdev= 5.28 clat (msec): min=1, max=209, avg=18.25, stdev=12.51 lat (msec): min=1, max=209, avg=18.27, stdev=12.51 bw (KB/s): min= 3048, max= 3840, per=100.16%, avg=3505.55, stdev=113.92 cpu: usr=1.02%, sys=2.17%, ctx=36213, majf=0, minf=37 IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0% issued r/w/d: total=38595/0/0, short=0/0/0 lat (msec): 2=0.01%, 4=0.47%, 10=21.24%, 20=48.90%, 50=26.46% lat (msec): 100=2.79%, 250=0.13%

Запись:
Конфиг fio[readtest] blocksize=4k filename=/dev/drbd0 rw=randread direct=1 buffered=0 ioengine=libaio iodepth=16

Вывод fiowritetest: (groupid=0, jobs=1): err= 0: pid=5229 write: io=2396.0KB, bw=109341 B/s, iops=26, runt= 22439msec slat (msec): min=8, max=67, avg=37.40, stdev= 9.43 clat (usec): min=440, max=741029, avg=553594.77, stdev=83784.27 lat (msec): min=40, max=783, avg=590.99, stdev=86.72 bw (KB/s): min= 6, max= 131, per=98.23%, avg=104.12, stdev=19.29 cpu: usr=0.30%, sys=0.11%, ctx=601, majf=0, minf=20 IO depths: 1=0.2%, 2=0.3%, 4=0.7%, 8=1.3%, 16=97.5%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete: 0=0.0%, 4=99.8%, 8=0.0%, 16=0.2%, 32=0.0%, 64=0.0%, >=64=0.0% issued r/w/d: total=0/599/0, short=0/0/0 lat (usec): 500=0.17% lat (msec): 50=0.17%, 100=0.17%, 250=0.83%, 500=14.36%, 750=84.31%

Чтение не деградировало или почти не деградировало. Запись деградировала во много раз (напоминаю, drbd находится в StandAlone-режиме)

Кроме того, присутствует страшная задержка на slat — больше 37 мс только на обработку io-запроса дисковым стеком.

Что я делаю не так с drbd? Это же ненормальное поведение, когда просто еще один слой (drbd over md) рубит производительность в сорок раз?

DRBD 8.3, ядро 3.5.0-27-generic, система Ubuntu 12.04 LTS. Планировщик io — cfq.

Помогите?

Есть старый сайт, который был перенесен на SimplaCMS. Изменилась структура URL и нужно сделать редирект со старых страниц на новые.

Файл хтаццес имеет такой вид: (редиректы в конце самом)

AddDefaultCharset UTF-8

ErrorDocument 404 /404

ErrorDocument 401 /password.php

RewriteEngine on

# Админка теперь по адресу /simpla

RewriteRule ^admin/?$ simpla [L]

# Каталог товаров

Проблема выглядит примерно так:
Есть сервер с рейд контроллером (perc H700m) на Ubuntu 12.04, я пытаюсь создать программный рейд 1 на двух дисках по 3тб, отделив через gdisk 2 раздела по 300гб и один на 500гб на каждом из дисков пытаюсь соответственно собрать массивы.
Первое что показалось странным, возможно это от того, что контроллер для того чтобы подклчюить одиночный диск как бы помещает его в рейд0.
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1 mdadm: /dev/sda1 appears to be part of a raid array: level=raid0 devices=0 ctime=Thu Jan 1 03:00:00 1970 mdadm: partition table exists on /dev/sda1 but will be lost or meaningless after creating array mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid0 devices=0 ctime=Thu Jan 1 03:00:00 1970 mdadm: partition table exists on /dev/sdb1 but will be lost or meaningless after creating array mdadm: size set to 314441536K
То же самое и на остальных.
Массив создается, дальше я его отдаю через tgt по iscisi.
Добавляю в /etc/mdadm/mdadm.conf мои массивы.
ARRAY /dev/md0 UUID=fd798c1c:baf4f1a9:682aab93:740a5f7b ARRAY /dev/md1 UUID=3a45134d:334b408a:64bcef42:3c7faf9e ARRAY /dev/md2 UUID=a9e82c0e:384fb9b8:6eed8296:8c7eaab6
Всё работает до ребута, после ребута стартует один массив md2 и начинет его синхронизировать.
Если сделать после ребута mdadm -A --verbose /dev/md0 валится что-то вроде:
mdadm: no RAID superblock on /dev/sda1 mdadm: Cannot assemble mbr metadata on /dev/sda1 mdadm: no RAID superblock on /dev/sdb1 mdadm: Cannot assemble mbr metadata on /dev/sdb1

Прошу помощи сообщества. Есть линуксовый сервер на хецнере — с двумя SATA дисками, объединёнными в зеркало (RAID 1) при помощи mdadm. Вылетел один из дисков. После замены, пробую сделать ребилд массива. Ребилдятся все разделы кроме одного — новый диск упорно встаёт как SPARE. Это выглядит следующим образом:

=========
cat /proc/mdstat
Personalities: [raid1]
md0: active raid1 sda1[2] sdb1[1]
33553336 blocks super 1.0 [2/2] [UU]

md1: active raid1 sda2[2] sdb2[1]
524276 blocks super 1.0 [2/2] [UU]

md127: active raid1 sda5[2](S) sdb5[0]
2110014324 blocks super 1.0 [2/1] [U_]
=========

Ни гугление, ни танцы с бубном и ключами mdadm результата не достигли.
Господа и дамы, подскажите пожалуйста, как всё-таки сделать sda5 полноценным членом рейда?

Сервер CentOS, на нём nginx и php-fpm, собранные из исходников. Понадобилось добавить поддержку memcached.

Установил libmemcached и php memcached — всё тоже из исходников. Добавил строку php_admin_value[extension]=memcached.so в конфиг php-fpm и перезапустил его.

Тестовый php на веб сервере показывает секцию про memcached в phpinfo(), но в этом же файле попытка инстанциировать этот класс даёт фатальную ошибку «Class 'Memcached' not found».

Точно такая же ситуация с php расширением memcache (без «d»). Есть в phpinfo(), «Class not found» при попытке работать с классом.

ЧЯДНТ и как правильно подключить поддержку memcached из исходников в php-fpm?

Сначала немного вводных данных:
Есть сервер на базе Edubuntu 12.04, на нем поднят LTSP, система на SSD, /home размещен на аппаратном рейде, админ с линухом не дружит ).

1. Допустимо ли размещение расшареных папок и бэкапов непосредственно в /home (не в папках пользователей)? Насколько это «идеологически» верно…
2. Можно ли как-то оптимизировать процесс настройки терминальных учетных записей? К примеру: нужно для любого вновь созданного пользователя(а также и уже существующих) оперативно применить настройки того же рабочего стола, прокси и прикладного ПО по шаблону с конкретно указанной учеткой, совершать автоочистку пользовательских каталогов по завершению сеанса/временному промежутку. Если да, то как?
3. Клиенты (тонкие и не очень) различаются по аппаратному обеспечению, в связи с чем происходит потеря производительности. От чего конкретно зависит качество воспроизведения видео на терминалах при использовании LTSP (графический адаптер, память...)? Непонятно ведет себя и сеть, например подключенный по гигабитному соединению современный ноутбук работает идеально, канал связи забивается до значений порядка 40Мбит, но зато никаких артефактов и торможений картинки не наблюдается, однако этот же ноутбук, подключенный по каналу 100Мбит воспроизводит то же самое видео в режиме слайдшоу, а исходящий с сервера поток урезается до ~10Мбит…

Может быть есть какое-нибудь средство для мониторинга текущей нагрузки на компоненты клиента, благо определяются они вполне корректно(судя по тому, что работают без проблем)?
UPD: 3 вопрос переходит в разряд философских. Исходя из статистики использования канала можно сделать один вывод — с современными разрешениями экранов для комфортной работы потребуется не менее 10 честных мегабит. Для просмотра видео в достаточно высоком качестве канал нужен в пять раз быстрее.
Хабравчане — не молчите, иначе вопрос превратится в статью :)

В веб-интерфейсе supervisord (supervisord.org/) напротив сервиса есть ссылка «Tail -f» (адрес такой: site.ru:9001/logtail/service_name%3A0). При нажатии на данную ссылку открывается новое окно, но ответ так и не приходит в браузер. Из консоли supervisorctl аналогичный вызов (tail -f service_name:0) отрабатывает нормально.

supervisor> tail -f service_name:0 ==> Press Ctrl-C to exit

Привет

В продакшине есть сервер dell poweredge r720xd с windows server 2012 datacenter edition, он забсодил после того как я отправил виртуальную машину в ребут.

интересное из мини дампа:
Технические характеристики kd>! analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Добрый вечер!

У меня есть ресурс на облачном хостинге. Там есть скрипт поиска. Идет поиск по нескольким таблицам, но FULLTEXT индекс только у одного поля ( articles.article_text_for_search ). Объемы текстов по которым ведется поиск — большие. Количество записей в articles — 3 000

Дело в том, что когда работает скрипт search.php ( а это около 8-ми секунд ) — то остальные страницы с сайта, если их попробовать загрузить — сразу не отдаются. Отдаются только когда скрипт search.php начинает отдавать контент в браузер…

Хостер говорит, что это я виноват. И больше ничего не говорит. Я не гуру mysql, но как SELECT запросы могут мешать отдачи контента? ( LOCK Tables не использую, тип таблиц везде — MyISAM )

SELECT articles.id, articles.magazine_id, articles.issue_id, articles.article_name, articles.annotation, articles.article_text, SUBSTRING( articles.article_text, 1, 1000) as article_text_1, articles.section_id, articles.article_rating, articles.to_main, articles.article_unix_add, magazines.mag_name, magazines_issues.issue_number, GROUP_CONCAT( users.user_name ) AS user_names, GROUP_CONCAT( users.user_surname ) AS user_surnames,

Добрый день.

Столкнулся со следующей ситуацией.

Есть сервер с Debian Squeeze, на нём установлен nginx 0.7.67 (из репозитория).

В принципе, всё работает без проблем, но заметили, что иногда не получается приконнектиться к порту. SYN приходит, ответа нет.

Пробовал включить syncookies, это несколько помогло (в логах вылезли ошибки про «possible SYN flooding on port 80. Sending cookies.»). Но всё равно были проблемы с коннектом. Синфлуда при этом нет, это просто много легального трафика.

После этого, увеличил следующие параметры:
net.core.somaxconn = 128000 net.core.netdev_max_backlog = 10000 net.ipv4.tcp_max_syn_backlog = 128000'

У нжинкса увеличил listen backlog до 65536.