Есть довольно стандартная конструкция: несколько серверов с приложением на PHP, использующим в качестве кеша несколько memcached-серверов.

Мне не хватает понимания, как вся эта конструкция себя ведет при нештатных ситуациях - в частности, как распределяются ключи по серверам, что происходит при падении одного или нескольких memcached-серверов, почему могут возникать ситуации с разными данными на разных php-клиентах и т.д.

Посоветуйте что-нибудь почитать на эту тему.

В какой-то момент начал подвисать Chromium: полностью фризится весь его интерфейс на секунду-две. Может замереть даже посередине анимации закрытии/открытии вкладки. В момент фриза другие приложения работают ок.

Происходит это, в основном (но не всегда!), при открытии/закрытии вкладок, при вводе в адресную строку чего-либо, иногда - просто на ровном месте. Если браузер запущен давно, вероятность фриза при открытии новой вкладки растет.

Кроме браузера, проблема явно наблюдается и в приложениях на базе Electron - они тоже иногда подвисают.

Проблема есть и под иксами, и под wayland. От окружения (GNOME, Mate) тоже не зависит. Производительности компа должно хватать с избытком (i7-8700, SSD). Дистриб - арч, видеокарта Intel.

Проблеме уже года два наверное. Что можно посмотреть, куда копать?

Имеем дамп базы MySQL в виде dump.sql, который импортируем в чистую, только что созданную БД.

Так вот, в macOS импорт *.sql-дампов работает значительно (в разы - см. ниже) быстрее, чем под Linux.

Ситуацию эту наблюдаю уже не первый год, и принципиально она не меняется при смене версий MySQL, железа, дистрибутива, дампов и т.д.: разрыв от случая к случаю меняется (разное железо, разные дампы и т.д.), но мак всё равно значительно выигрывает минимум вдвое.

Для простоты и наглядности выбрал два основных конфига и провел тест на дампе, с которым работаю сейчас:

Мак: ноут Macbook Pro mid-2014, Core i5-4278U (2 ядра, 2.6GHz), SSD, файловая система HFS+,

Linux: десктоп с Core i7-8700 (6 ядер, 3.2 GHz), диск - NVMe, файловая система XFS.

Строго говоря, есть разница в версиях MySQL: сейчас на Linux стоит Percona 8.0.20-11, на маке - MySQL 5.7.29 (из репов Homebrew), но, повторюсь, это погоды не делает - когда стояли одинаковые версии, ситуация была такой же.

Время импорта одного и того же дампа (размер - 308М):

Мак - полторы минуты:

real    1m30.316s
user    0m17.720s
sys     0m1.150s

Linux - более двадцати минут:

real    20m14.797s
user    0m9.236s
sys     0m2.626s

При импорте под маком процесс MySQL нагружает CPU на 70-80%, под линуксом - на 15-25% (оба показателя - на глаз через htop).

ИМХО, разница слишком большая, чтобы подозревать железо - следовательно, дело должно быть в конфигах.

На какие опции конфигов стоит посмотреть? Что ещё, кроме конфигов, может влиять?

Буду рад любым идеям.

Всем привет. Столкнулся с довольно странной проблемой, которая повторилась дважды. За более чем 10 лет работы с Linux такого ещё не видел, но в чем подвох - понять не могу.

Итак, имеем: Linux Mint 17.3 x86_64, ядро 3.19.0-32-generic, установленный на обычный HDD поверх LVM на ext4. В попытке №1 весь диск был отдан под один раздел на всё. Проработало это дело пару месяцев, пока в один прекрасный день в попытке обновиться я получаю сообщение, что мол read-only filesystem. Проверяю - да, правда, корень подмонтирован в read-only. Запускаю fsck, он находит невероятную кучу ошибок, в итоге теряю кучу файлов, включая весь /etc, система естественно после этого не грузится, занавес.

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

Переустанавливаю всё с нуля. На этот раз решил отделить часто пишущееся от остального, в итоге /home, /tmp, /var, разделы для торрентов и виртуалок подключены отдельно.

Проработало это меньше недели, нештатных отключений и перезагрузок не было, но вот только что, решив установить пакет, получаю ту же ошибку - read-only filesystem. И правда: корень перемонтировался в ro, и fsck находит ошибки (хоть и в меньшем количестве, но тоже немало). На этот раз система вроде жива, но это всё очень настораживает.

Куда копать, что может быть? С железом вроде бы всё в порядке, memtest не ругается, диск без бэдов, в dmesg ошибок нет.

Я думаю, проблема довольно классическая, но так как в iptables я все еще плаваю (ибо редко с ним имею дело), понятного мне решения я так и не нашел.

Итак, имеем: 1. Комп, выступающий в роли роутера. На нем Linux с iptables. 2. Сервер с nginx внутри локалки, на который проброшен 80-й порт. 3. Рядовые компы внутри локалки, которые получают доступ в инет через вышеупомянутый роутер.

Все работает как надо, но есть одна проблема: в логах nginx все запросы к серверу извне видны как будто они идут от внешнего IP роутера, и как следствие имеем ряд неприятных последствий.

iptables на роутере настроен следующим образом:

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/$INET_IFACE/proxy_arp

# Clear ALL rules
$IPTABLES -F
$IPTABLES -X
$IPTABLES -t nat -F
$IPTABLES -t nat -X
$IPTABLES -t filter -F
$IPTABLES -t filter -X
#----------------------------------------------------------------------------------------------------------
# POSTROUTING chain
$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -s $LAN_IP_RANGE -j SNAT --to-source $STATIC_IP

# Port forwarding
$IPTABLES -t nat -A PREROUTING -p tcp -i $INET_IFACE --dport 80 -j DNAT --to 192.168.0.2:80

# Forwarding itself
$IPTABLES -t nat -A POSTROUTING -o $LAN_IFACE -j SNAT --to-source $STATIC_IP

# Forward to connect via local net to external IP
$IPTABLES -t nat -A PREROUTING -i eth0 -p tcp -m tcp -d $STATIC_IP/32 --dport 80 -j DNAT --to-destination 192.168.0.2:80

В логах nginx виднеется такое (AA.BB.CC.DD - внешний IP роутера):

2014/01/18 00:22:16 [error] 2607#0: *11106146 limiting connections by zone "conn_limit_per_ip", client: 192.168.0.1, server: localhost, request: "POST /index.php HTTP/1.1", host: "AA.BB.CC.DD"

Как сделать так, чтобы были видны именно внешние IP-адреса тех, кто шлет запросы?

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

Вопрос в общем-то заключается в том, что за вид оптоволокна для этого нужен. Я в нем совершенно не разбираюсь, и не представляю как гуглить.

Поставил себе e17 на потыкать. Основная проблема - нет трея. Гугл указывает на то, что его надо включить (настройки->модули->системный лоток), но его включение ни к чему не приводит.

Есть подозрение, что он вообще сломан. Поэтому, хочется примеров у кого это работает (если таковые вообще есть).

Воспроизводится так: 1) открываем какой-нибудь архив 2) копируем из него пачку файлов в соседнюю панель (F5).

Если архив - tar.gz или подобный, то всё происходит очень быстро, как и положено. Если же архив в формате zip, то распаковка идет с чудовищно низкой скоростью (причем скорость явно зависит от количества файлов).

Это какие-то фундаментальные ограничения формата, или же баг? Наблюдаю абсолютно во всех версиях mc вне зависимости от дистрибутива.

Вроде, на лоре были разработчики GIMP'а, посему вопрос: для чего в 2.7.х разделили сохранение и экспорт? Раньше я жал Ctrl-Shift-S, и сохранял в том формате, в котором мне в данный момент надо (будь то xcf или jpeg или png), теперь Ctrl-Shift-S позволяет сохранить только в XCF, а для других форматов - отдельный диалог (Ctrl-Shift-E).

Мне кажется, это не очень удобно, поэтому интересно, согласно какой логике так было сделано?

В компе 3 харда, и один из них фактически не используется уже очень давно. И этот неиспользуемый диск внезапно взял и помер: в dmesg валится вот такое:

[97402.720049] ata7: lost interrupt (Status 0x50)
[97402.720066] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[97402.720069] ata7.00: failed command: READ SECTOR(S)
[97402.720073] ata7.00: cmd 20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
[97402.720074]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[97402.720076] ata7.00: status: { DRDY }
[97402.720090] ata7: soft resetting link
[97402.880763] ata7.00: configured for PIO0
[97402.880775] ata7: EH complete

Проблема в том, что разные вещи, которые по природе своей работы опрашивают все харды (например, vgdisplay и lvresize), жутко тупят и ругаются на ошибки ввода-вывода.

Есть ли способ отключить диск удаленно? Диск, само собой, внутренний, а подключен по IDE. Ехать вынимать физически - лень очень :)

Уже очень давно на одном компе у меня есть проблема: где-то за неделю память забивается под 3 гига, и даже если выгрузить иксы, все демоны, и остаться в голой консоли (login, getty, bash), все равно остается занятым около 2 гигабайт. Из этого логика мне подсказывает, что течет что-то на уровне ядра.

Так как при абсолютно идентичном наборе софта и методах работы на других компах подобного не возникает, интуиция указывает на разницу в железе, и как следствие - на разницу в используемых драйверах. И эта разница называется ATI Radeon.

Конечно, было бы намного проще просто поменять видеокарту, но хочется пойти более сложным путем: найти таки источник проблемы и попытаться его исправить. Я в ядерной отладке вообще полный ноль, поэтому хотелось бы услышать советов по поводу того, с чего лучше начать.

Прислали мне psd. Открываю в GIMP, всё вроде хорошо. Потом оказалось, что у объектов нет теней, хотя они должны там быть. Выяснилось, что тени были указаны как эффекты слоя, и похоже что GIMP (2.6.11) их не умеет (мне нужен всего лишь банальный drop shadow). В принципе, под рукой есть мак с фотошопом, но во-первых в гимпе мне работать удобнее и привычнее, а во-вторых, на двух компах сразу работать не очень удобно.

Кто что посоветует для выхода из данной ситуации? Стоит ли пробовать собрать gimp 2.7.4?

Чтобы было понятнее, о чем речь, вот скриншот.

Бяка эта проявляется на 0.9.0, 0.9.1.90, и 0.9.2.0.

Пакеты NetworkManager, network-manager-applet, NetworkManager-pptp и NetworkManager-openvpn, само собой, установлены, но очевидно собраны либо неправильно, либо имеет место какой-то upstream bug.

Уже как только можно пересобирал, не знаю куда дальше копать, подбросьте идей.

Всем привет!

Так уж сложилось, что мне достаточно часто приходится заниматься конвертацией видео из/в различные форматы. Делаю это в консоли, но данный подход имеет ряд недочетов:

• Постоянно забываются нужные ключи (особенно для сложных и/или редких случаев),
• Есть некоторый геморрой с пакетной обработкой в случаях, когда на входе - файлы с именами, содержащими спецсимволы (типа длинной мути с кириллицей, скобочками и пробелами),
• Есть желание сделать данный процесс доступным не только для меня, чтобы сделать данную часть рабочего процесса независимой от единственного человека, посвященного в эти дебри.

Чтобы не писать велосипед, а так же изучить ошибки существующих фронтендов, ищутся все существующие GUI для ffmpeg, в первую очередь - развивающиеся и кроссплатформенные.

Пока наткнулся только на WinFF, но оно на дельфях/лазарусе, и это, понятное дело, плохо.

Так же приветствуются всяческие идеи и пожелания на этот счет :)

Поясните, как такое может быть:

aix@aix27249:~$ free
             total       used       free     shared    buffers     cached
Mem:       4046332    3176544     869788          0      30296     353400
-/+ buffers/cache:    2792848    1253484
Swap:      5242876    2663368    2579508

скрин htop'а: http://rghost.ru/23637631/image.png

Собственно, в чем вопрос: как видно, занято очень много памяти - более пяти гигабайт, при этом система глубоко ушла в своп. Из суммы RSS запущенных процессов никак такое число не складывается.

Куда еще может расходоваться память? Приведенная выше картина рушит мои представления о распределении памяти.

Очевидно, что-то течет, но я не могу понять что именно. Может ли это быть в данном случае ядро, и если да - то как выявить данный факт?

Проблема на самом деле весьма не новая, ей где-то года полтора. Суть заключается в том, что при интенсивной работе с USB Flash накопителями, а как выяснилось недавно - так же и при интенсивном чтении с DVD-ROM, система начинает как бы тупить: подвисания мышки, заедание звука, и так далее.

Проявляется это дело на совершенно разных компах, под разными версиями ядер (и от версии к версии ничего не меняется). Единственное общее - ядра собраны приблизительно однотипно (ядро дистрибутивное, а дистриб везде один и тот же).

На разном железе тормозит по-разному: где-то еле заметно, а где-то вообще работать невозможно становится. С производительностью железа в целом это никак не коррелирует.

Важный момент: при операциях с хардом или NFS/Samba таких эффектов никогда не возникает.

Поясните мне: связано ли это как-то с пресловутым 12309, или же это баг совсем другой природы?

Как с этим обстоят дела у вас?

Есть сервер на винде 2к3, на нем расшарена директория. Эта директория смонтирована на Linux-компе.

fstab:

//192.168.16.251/share 				/mnt/hd 	cifs 	noauto,user=my_username,uid=1000,gid=1000,password=1234,soft,sec=ntlmv2i 	0 0

В какой-то момент начались проблемы при записи в эту директорию: при записи любого файла любого размера запись зависает: ждать можно сколько угодно. В dmesg при этом появляется следующее:

[  288.992034] CIFS VFS: sends on sock ffff8800d52398c0 stuck for 15 seconds
[  288.992039] CIFS VFS: Error -11 sending data on socket to server
[  299.072527] CIFS VFS: Unexpected SMB signature
[  325.016019] CIFS VFS: sends on sock ffff8800d65b5080 stuck for 15 seconds
[  325.016023] CIFS VFS: Error -11 sending data on socket to server
[  335.018804] CIFS VFS: Unexpected SMB signature
[  636.108016] CIFS VFS: Server 192.168.16.251 has not responded in 300 seconds. Reconnecting...
[  636.126914] CIFS VFS: Unexpected SMB signature
[  656.144028] CIFS VFS: sends on sock ffff8800d6632940 stuck for 15 seconds
[  656.144032] CIFS VFS: Error -11 sending data on socket to server
[  666.156752] CIFS VFS: Unexpected SMB signature

Первый раз добавил опции soft,sec=ntlmv2 - помогло, но сегодня проблема всплыла опять, поэтому я думаю что эти опции не влияют на нее.

Других linux-машин в округе нет, зато есть маки - на них всё ок (но там монтирование идет через smb, а не через cifs).

Проблема наблюдается исключительно при записи - чтение файлов, создание директорий, удаление файлов работает без проблем.

Гугление не помогает (отчасти из-за нулевого опыта с проблемами самбы - никогда не сталкивался), подскажите куда копать?

p.s. kernel 2.6.39.1, samba 3.5.8

Суть такова: в обычной консоли можно листать вывод клавишами Shift-PageUp и Shift-PageDown, но в screen это не работает. Как (и возможно ли вообще) его этому научить?

По мотивам только что удаленного треда, а так же причины его удаления, возник интересный вопрос: а почему у всех одинаковые результаты, даже не смотря на то что процессоры очень разные?

Возник тут интересный вопрос. Как известно, довольно многие люди, так или иначе связанные с IT (в первую очередь - из linux-сообщества), любят аниме. С другой стороны, многие анимешники так или иначе интересуются IT (вплоть до вливания в ряды Ъ-линуксоидов).

Почему такая тесная взаимосвязь? С чем это может быть связано? Какие могут быть этому первопричины?

p.s. Сам отношусь к аниме нейтрально.