From: Eugene Grosbein grosbein.net 16 Feb 2019 03:43 +0200
To: Alex Korchmar ddt.demos.su
Subject: дебаг
15 февр. 2019, пятница, в 18:32 NOVT, Alex Korchmar написал(а): SA>> Я так понимаю пpидется мне хаpд куда-то совать в дpугое место AK> хотя бы смонтировать с другой флэшки, где эта fs не импортилась, чтобы AK> можно было быть уверенным, что там никто не лазит. Зачем нужна эта уверенность, когда мы как раз и испытываем на прочность способность fs восстанавливать свою консистентность? Речь же не идёт о данных в базе MySQL, например. Eugene -- Что делать?! Мир стоит на воровстве!.. Воруют в Самарканде и в Хиве, В Ширазе, в Тегеране и в Стамбуле И даже - страшно вымолвить - в Москве!..
From: Eugene Grosbein grosbein.net 13 Feb 2019 00:57 +0200
To: Slawa Olhovchenkov 2:5030/500
Subject: висим стабильненько
25 марта 2018, воскресенье, в 17:45 NOVT, Slawa Olhovchenkov написал(а): SO> ты зря так думаешь. SO> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP SO> mbuf_jumbo_page: 4096, 16777216, 987894, 759655,8205734907395, 0, 0 SO> вот тебе пожалуйста 3ГБ свободной память в mbuf. SO> она действительно свободная, т.е. сейчас не используется mbuf jubmbo. SO> а я видел и 40ГБ. SO> и когда у нас будет дефицит памяти, ты можешь быстро-быстро конечно что-то из SO> ARC выкинуть. SO> только во-первых это будет все же что-то наверное нужное, в отличии от SO> вышепоказанного. а во-вторых оно вообще-то не попадет в систему. оно попадет во SO> что-то типа (если специально не применить некоторых трюков, а трюки эти таки SO> немножко дорогие, см.ниже.) SO> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP SO> zio_data_buf_1048576: 1048576, 0, 217577, 1604,14972433811, 0, 0 SO> (вот тут у нас 1.6Г свободной памяти) SO> и потом её оттуда достанут, если pressure будет продолжаться. как и из jumbo. и SO> из остальных мест. и после этого свободной памяти окажется ДОХУЯ. SO> но а) это будет потом б) мы уже повыкидывали всякое из ARC да и ARC зачем-то SO> уменьшили в) это затратный по CPU процесс и вдобавок он тормозит много что, т.к. SO> при этом происходит contention lock (причем по памяти). SO> пункт в) -- он из-за оптимизации под SMP: для того, что бы всякие подсистемы не SO> дрались постоянно за один lock при alloc/free они живут по зонам. и если если в SO> зону память берут достаточно дешево, то обратно в систему ты её дешево вернуть SO> не можешь -- надо будет брать глобальный лок, вертать память, освобождать лок. SO> это дорого. поэтому free память помещает во внутризоновый free. из него в SO> систему подбирает кажется pagedaemon, когда начинают стучать по балде "freepages SO> меньше лимита! ааа!". но как уже сказанно -- это дорогая операция -- локи и все SO> такое. Hа 11.2-STABLE/amd64 r335757 что-то "потом" у меня так и не произошло на восьми гигабайтах RAM, когда память кончилась совсем: ZFS ARC выкушал немного менее своего лимита в 3GB, firefox выжрал 5GB RSS плюс Xorg плюс xfce4, в итоге в свопе более 3.5GB, Free около нуля, Wired более 4.5GB, полный трешинг vm с десятками мегабайт page-in/page-out в секунду, firefox убивался несколько минут, хотя и сдох в конце концов. Я даже после этого вышел в single user mode и экспортировал пул ZFS, что дропнуло размер ARC до 44 мегабайт, но Wired остался как был, включая 1.8 гигабайта "свободных" в adb_chunk и более 450 мегабайт в dnode_t, 350M в zio_buf_512, 226M в zio_buf_16384, 173M в dmu_buf_impl_t и ещё 136M в zio_data_buf_131072. Где всё это время был pagedaemon, я так и не понял. Eugene
From: Eugene Grosbein grosbein.net 11 Feb 2019 19:34 +0200
To: Sergey Anokhin 2:5034/10.999
Subject: дебаг
11 февр. 2019, понедельник, в 08:47 NOVT, Sergey Anokhin написал(а): >> Такое еще словил SA> эмпирически выявил что ядро в корку падает когда идет инсерт в базу, SA> таблицы большие, файлики большие, может и зфс поломали или память SA> глючит...пробовал отключать лимит на arc и компрессию не помогло. SA> пробовал базы утаскивать на ufs раздел тоже не помогло. SA> все это странно Обновление до 12 теоретически могло сделать твой пул ZFS несовместимым с ядром 11.2, особенно если ты апгрейдил пул. Апгредил? У тебя зеркало ZFS? Eugene -- Поэты - страшные люди. У них все святое.
From: Eugene Grosbein grosbein.net 29 Jan 2019 08:20 +0200
To: Sergey Anohin 2:5034/10.1
Subject: 12-STABLE+racoon
28 янв. 2019, понедельник, в 20:02 NOVT, Sergey Anohin написал(а): SA> Hу да, там на экран писало кучу всего, но не заснять никак было. SA> Пока известно точно что вызывал краш старт racoon, я его пока выпилил из SA> автозагрузки. SA> Буду пробовать инсталлить еще раз ядро, потом стартовать racoon onestart, потом SA> после ребута смотреть корки, так? Так. Eugene -- Сердце - малочувствительный, мускулистый, грубый и жесткий орган.
From: Eugene Grosbein grosbein.net 28 Jan 2019 08:25 +0200
To: Alex Korchmar ddt.demos.su
Subject: rc.d and environment
26 янв. 2019, суббота, в 13:08 NOVT, Alex Korchmar написал(а): VS>> /usr/local/etc/rc.d/mydaemon start", то все переменные среды рута попадут в VS>> окружение mydaemon, т.к. в самих rc-скриптах никакая очистка не AK> предусмотрена. AK> поэтому service - ненужное говно, принесенное мудаками из линукса чтобы AK> не учиться ничему. Hа самом деле нет - service чистит environment. Именно поэтому некоторые мои скрипты, передающие контекстно-зависимую информацию в firewall_coscripts, вынуждены делать env VAR=value /etc/rc.d/ipfw start вместо service ipfw start при запуске из ip-up. Eugene
From: Semen Panevin 2:5025/121 25 Jan 2019 07:06 +0200
To: Alex Korchmar <1187511171@ddt.demos.su>
Subject: nginx+fastcgi запустить не могу
Доброго здоровьица тебе, Alex! Thursday January 24 2019 23:31, Alex Korchmar писал Semen Panevin: AK> dreamwidth заблокирован роспозором за распространение сведений, AK> разрушающих картину мира рассейских рабов. А, эти... >> Alex AK> P.S. отдельный вопрос - как можно быть it-специалистом (раз ты читаешь AK> эху для узкоспециального круга людей) настолько незамутненного AK> сознания, что a) самому не сообразить b) не найти за пятнадцать секунд AK> не менее трех способов решить проблему. Я знаю как решить эту проблему, другой вопрос что я а) не знаю что это именно она (на другие заблокированные сайты мой интернет-провайдер отдаёт более другие, ставшие уже привычными, респонзы) и б) я не уверен что мне надо её решать. Лично у меня nginx работает (точнее работал ради экспериментов, я всё равно остался на апаче, в nginx в то время я нашёл баги несовместимые с хостящимися у меня приложениями и их багами). Ну и в) можно было бы описание решения запостить сюда а не кидать ссылку. Мы же всё-таки в фидо а не в интернете. С наилучшими пожеланиями, Семён. ... Если человек родился, то это уж на всю жизнь... (c)...
From: Eugene Grosbein grosbein.net 25 Jan 2019 06:39 +0200
To: Sergey Anohin 2:5034/10.1
Subject: 12-STABLE+racoon
24 янв. 2019, четверг, в 03:12 NOVT, Sergey Anohin написал(а): SA> Сабж вызывает панику в селе при запуске, ОС ребутится циклично. SA> Походу кто-то что-то поломал...Есть инфа об этом какая-то? Пробежался поиском SA> по UPDATING SA> не нашел про racoon или ipsec. Пересборка ipsec-tools не помогла Включи выдачу KDB_TRACE, запись крешдампов, покажи что напишет. Eugene -- Тестоголовые кислое свое брожение приняли за душу, распарывание чрев своих - за историю, средства, оттягивающие разложение - за цивилизацию...
From: Sergey Zabolotny 2:469/122.2 19 Jan 2019 23:41 +0200
To: Eugene Grosbein grosbein.net
Subject: iptv
Hello *Eugene.* Sunday 20 January 2019 03:31, Eugene Grosbein wrote to Sergey Zabolotny: SZ>> Местный провайдер до недавних пор транслировал мультикаст из SZ>> подсетей 224.20.20/24, 224.21.21/24 и 224.24.24/24. все эти сети SZ>> были просканены и собран полный список каналов (включая SZ>> запрещенные, которые местными богами считаются рос пропагандой). SZ>> С недваних пор каналы из подсетей 21.21 и 20.20 перестали SZ>> отвечать, в итоге остался один сплошной трэш, который мне SZ>> смотреть не интересно. Хочется вернуть остальную часть каналов. SZ>> Скан всей мультикаст подсети (даже если предположить, что SZ>> мультикаст порт остался прежним) может занять непомерно много SZ>> времени. Какие есть еще варианты определить, куда были перемещены SZ>> каналы? тисипидампом вижу только пакеты 224.24.24/24, дгуих SZ>> мультикаст адресов не видать. EG> Они могли никуда не быть перемещены, а просто на оконечных свичах EG> настроены наконец IGMP ACL, фильтрующие запросы multicast join от тебя EG> и остальных клиентов. Чтобы в соответствии с тарифом или ещё какими EG> высшими соображениями выдавать разным клиентам разные подмножества EG> имеющихся каналов. достоверно не известно, что было сделано, чтоб сломалось то, что раньше работало. в общем я понял, что это гиблое дело пытаться отломаные каналы как-то восстановить. надо искать другие источники. кстати, может кто знает, где берут стабильно работающие потоки?
From: Dmitriy Smirnov 2:5010/352@fidonet 11 Jan 2019 14:40 +0200
To: Sergey Zabolotny 2:469/122.2
Subject: ipv6 на arubacloud
hi, Sergey! 11 Jan 19 09:25, Sergey Zabolotny wrote to Dmitriy Smirnov: DS>>>> в линупсе я перевожу раздел в рескью и закатываю на устройство DS>>>> готовый образ, по времени еще быстрее получается чем DS>>>> манимуляции с разделами. SZ>>> ну вот перенес все, что было на арубе в другое место, буду SZ>>> эксперементировать. DS>> в другое, это в какое?) SZ> в хецнер. на дедик с виртуалками. :-) читер =) wbr, Dmitriy.
From: Alex Korchmar <1187511063@ddt.demos.su> 11 Jan 2019 07:18 +0200
To: Sergey Anohin 2:5034/10.1
Subject: zfs arc limit
From: Alex Korchmar Sergey Anohin wrote: > напомните плз, дабы не копать, историю как сейчас дела с сабжем, в каких все по прежнему - качаешь патч от slw, отключаешь abd sysctl'ом, опционально выключаешь compressed arc, и ничего не лимитируешь, память освобождается по мере необходимости, вся свободная используется под кэш. Как и должно быть. Можешь еще %$@дакам на зарплате от iX написать что они эти самые, но, полагаю, бесполезно. > Alex