А вообще хорошо что инсталятор начали делать людский. И убрали эту херню с кучей разделов.
VitalyMoiseev
2012-01-13 22:58:14
я на тестовой железяке обновил 8.2 PRERELEASE на 9.0-STABLE, с пересборкой всего - мира и всех портов (хотя вроде бы все завелось и без пересборки портов). Все работает, все отлично, хотя еще особо ничего не проверял. Никаких особых отличий не заметил, кроме /dev/ada
nightfly
2012-01-13 23:04:46
А вообще хорошо что инсталятор начали делать людский
И не стыдно? В церковь бы сходили, свечку поставили... после такого.
sysinstall был теплым и ламповым, испохабили.
alex_o
2012-01-14 00:25:19
Никаких особых отличий не заметил, кроме /dev/ada
сотонинсткая ось. И на лого - черт, и ад теперь напрямую доступен через /дев/
nightfly
2012-01-14 00:44:35
и ад теперь напрямую доступен через /дев/
Не, не напрямую - AHCI via the CAM (common access method for storage) subsystem.
Имха опять же ad9 раньше как-то каноничнее намекал на девятый круг ада чем теперь. И вобще раньше... деревья выше, трава зеленее, ад адовее.. и всякое такое, да?
ЗЫж а по теме - HAST еще никто не тестил?
Sargas
2012-01-14 01:02:34
А вообще хорошо что инсталятор начали делать людский
И не стыдно? В церковь бы сходили, свечку поставили... после такого.
sysinstall был теплым и ламповым, испохабили.
Он остался. После установки системы можно также запустить sysinstall и понастальгировать. Интересно если компилить ядро не gcc, а clang то шустрее будет или нет )
nightfly
2012-01-14 01:14:57
Он остался. После установки системы можно также запустить sysinstall и понастальгировать.
да, знаю, уже на него помасностальгировал
Интересно если компилить ядро не gcc, а clang то шустрее будет или нет )
Стремота конечно в продакшене-то, с другой стороны как минимум время сборки должно уменьшиться ощутимо (хотят еще и медитативную сборку отобрать гады?)
Sandorik
2012-01-14 01:15:23
Да. немного замарочаный установщик. выбора вариантов нет. создал два раздела, ufs и swap. нажал на финиш. установил но только почемуто оно установилось непонятно куда. загрузка и получаем grub-rescue...
adeep
2012-01-14 10:44:20
собранный clang не гоняли еще, а так уже месяца два работает на NAS - ведет себя намного лучше чем 8.х
VitalyMoiseev
2012-01-14 14:09:07
собранный clang не гоняли еще, а так уже месяца два работает на NAS - ведет себя намного лучше чем 8.х
а чем лучше? В разрезе именно НАСа? А то думаю - стоит ли свои апгрейдить или нусть пока под 8 работают
adeep
2012-01-14 14:57:23
собранный clang не гоняли еще, а так уже месяца два работает на NAS - ведет себя намного лучше чем 8.х
а чем лучше? В разрезе именно НАСа? А то думаю - стоит ли свои апгрейдить или нусть пока под 8 работают
у нас 8.х рандомно бутался с периодом 1час-7 дней.
Тут допилили isr и поисправляли баги в netgraph (летом 2011). С дополнительным патчем на параллельную обработку пакетов становится счастьем даже с em сетевушками на pppoe
tivi
2012-01-14 15:44:35
С дополнительным патчем на параллельную обработку пакетов становится счастьем даже с em сетевушками на pppoe
вот с этого места можно поподробнее, плз ?
или ссылку киньте где почитать.
снкс.
ps. сейчас один из НАСов на 8.* держит более 1500к ппое соединений (+ шейпера на нем же) и прожевывает порядка гига в каждую сторону (900к ппс суммарно в ЧНН) на сетевых PT. вот просто интересно можно ЕЩЕ что-то выжать ?
adeep
2012-01-14 16:37:41
С дополнительным патчем на параллельную обработку пакетов становится счастьем даже с em сетевушками на pppoe
вот с этого места можно поподробнее, плз ?
или ссылку киньте где почитать.
снкс.
ps. сейчас один из НАСов на 8.* держит более 1500к ппое соединений (+ шейпера на нем же) и прожевывает порядка гига в каждую сторону (900к ппс суммарно в ЧНН) на сетевых PT. вот просто интересно можно ЕЩЕ что-то выжать ?
к сожалению, не доделан до конца, все никак руки не дойдут, но даже в этом состоянии работает отлично.
если у вас нет проблем с разделением по ядрам нагрузки, то вам это ничем не поможет
alex_o
2012-01-14 16:38:09
ps. сейчас один из НАСов на 8.* держит более 1500к ппое соединений (+ шейпера на нем же) и прожевывает порядка гига в каждую сторону (900к ппс суммарно в ЧНН) на сетевых PT. вот просто интересно можно ЕЩЕ что-то выжать ?
Если НАС уже молотит гиг, то куда Вы собрались выжимать больше?
Тут самое время делать из него 2 НАСа.
tivi
2012-01-14 18:21:01
Если НАС уже молотит гиг, то куда Вы собрались выжимать больше?
Тут самое время делать из него 2 НАСа.
так их и так два.
просто вот подумалось... знаете - всегда хочется еще лучше, хотя понимаешь, что лучшее враг хорошего...
вот будем делать самосборный третий на i2500k как тут на форуме советовали.
нагрузка (pppoe) на одно ядро под 90%. но это из-за объема трафика - практически прямая зависимость.
остальные - не больше 3-5%.
почему и интересовался по поводу распараллеливания нагрузки на ядра в 9-ке для pppoe (без участия дров от яндекса).
bit
2012-01-14 21:46:21
собранный clang не гоняли еще, а так уже месяца два работает на NAS - ведет себя намного лучше чем 8.х
а чем лучше? В разрезе именно НАСа? А то думаю - стоит ли свои апгрейдить или нусть пока под 8 работают
у нас 8.х рандомно бутался с периодом 1час-7 дней.
Тут допилили isr и поисправляли баги в netgraph (летом 2011). С дополнительным патчем на параллельную обработку пакетов становится счастьем даже с em сетевушками на pppoe
А что в 9ке в loader.conf sysctl.conf ?
ESP
2012-01-14 23:07:38
tivi
Ну с такими нагрузками на ЦП думаю действительно распаралеливание Вам будет в пору.
У меня аналогичная ситуация(1600 онлайн), аналогичные характеристики по всему, только транзитных 2 сетевых в lagg'е (1,2 Гб/с в пике) + яндекс-дрова.
Таким образом добился использования 4 ядер (в районе 30-40%).
привязка потоков isr к ядрам процессора. или в свободном плавании на усмотрение планировщика
nightfly
2012-01-16 16:22:02
Хм. Понаблюдал малость - вроде igb:que висят все восемь штук на своих ядрах, особо не мигрируя между ними. В любом случае пихнул для профилактики в лодер.конф на будущее. Спасибо.
net.isr.direct и net.isr.direct_force в FBSD9 получили статус устаревших.
вместо этого sysctl введен новый: net.isr.dispatch: deferred
Kto To
2012-01-17 07:39:35
Интересно.. а net.isr.direct что стоит?
net.isr.direct и net.isr.direct_force в FBSD9 получили статус устаревших.
вместо этого sysctl введен новый: net.isr.dispatch: deferred
спасибо. на счет loader.conf
hw.igb.max_unterrupt_rate=32000
hw.em.max_unterrupt_rate=32000
наверное interrupt_rate ?
да и у меня стоит карта PT но почему-то:
# sysctl -a|grep interrupt_rate
hw.igb.max_interrupt_rate: 8000
нету под hw.em этого значения...
adeep
2012-01-17 11:16:09
спасибо. на счет loader.conf
hw.igb.max_unterrupt_rate=32000
hw.em.max_unterrupt_rate=32000
наверное interrupt_rate ?
да и у меня стоит карта PT но почему-то:
# sysctl -a|grep interrupt_rate
hw.igb.max_interrupt_rate: 8000
нету под hw.em этого значения...
оно может быть только в некоторых версиях драйвера, может не быть видно после загрузки системы, может не существовать для конкретной модели вашей карты.
я не углублялся в анализ этого, задачей было составить максимально полный универсальный конфиг.
natiss
2012-01-18 16:04:57
На официаьном сайте все нововведения описаны.
Кстати ahci в ядре по умолчанию, это хорошо, но это не значит, что в 8-ке его нельзя было туда добавить. Драйвера новые с новыми глюками, строгий синтаксис /etc/rc.conf, иллюзия на систему органичения доступом к ресурсам racct. Xen как не было, так и нет, хотя libvirt появилась...
tivi
2012-02-07 14:42:51
в продолжении темы...
продолжаем оптимизировать 8.2
На сервере доступа упрощенно два интерфейса: igb0 - получаем канал и igb1 - отдаем по PPPoE.
т.к. PPPoE не паралелится по нескольким ядрам штатными средствами, то разумеется igb1 садится на первое (нулевое) ядро и выкушивает его под чистую.
и это не было бы большой проблемой, если бы на это же ядро не садились очереди от igb0 (которая садится на все ядра).
так вот вопрос - как сделать, что бы igb0 "лочилась" на все ядра кроме 0-го или начиная с 1-го и дальше ?
stroitel
2012-02-07 14:52:28
net.isr.direct=1
net.isr.maxthreads=X
так?
tivi
2012-02-07 14:55:54
первое и так включено, а второе - указываем какое максимальное кол-во ядер будем использовать.
а мне нужно, что бы использовало "все, кроме 0-го".
спасибо.
stroitel
2012-02-07 15:49:37
Перенесите irq и isr на другие ядра с помощью cpuset.
procstat -at
interjet
2012-11-25 06:19:34
в продолжении темы...
продолжаем оптимизировать 8.2
На сервере доступа упрощенно два интерфейса: igb0 - получаем канал и igb1 - отдаем по PPPoE.
т.к. PPPoE не паралелится по нескольким ядрам штатными средствами, то разумеется igb1 садится на первое (нулевое) ядро и выкушивает его под чистую.
и это не было бы большой проблемой, если бы на это же ядро не садились очереди от igb0 (которая садится на все ядра).
так вот вопрос - как сделать, что бы igb0 "лочилась" на все ядра кроме 0-го или начиная с 1-го и дальше ?
Кто уже обновился?
зачем что-то обновлять без необходимости...
а так бету ставил еще.
А вообще хорошо что инсталятор начали делать людский. И убрали эту херню с кучей разделов.
я на тестовой железяке обновил 8.2 PRERELEASE на 9.0-STABLE, с пересборкой всего - мира и всех портов (хотя вроде бы все завелось и без пересборки портов). Все работает, все отлично, хотя еще особо ничего не проверял. Никаких особых отличий не заметил, кроме /dev/ada
И не стыдно? В церковь бы сходили, свечку поставили... после такого.
sysinstall был теплым и ламповым, испохабили.
сотонинсткая ось. И на лого - черт, и ад теперь напрямую доступен через /дев/
Не, не напрямую - AHCI via the CAM (common access method for storage) subsystem.
Имха опять же ad9 раньше как-то каноничнее намекал на девятый круг ада чем теперь. И вобще раньше... деревья выше, трава зеленее, ад адовее.. и всякое такое, да?
ЗЫж а по теме - HAST еще никто не тестил?
Он остался. После установки системы можно также запустить sysinstall и понастальгировать. Интересно если компилить ядро не gcc, а clang то шустрее будет или нет )
да, знаю, уже на него помасностальгировал
Стремота конечно в продакшене-то, с другой стороны как минимум время сборки должно уменьшиться ощутимо (хотят еще и медитативную сборку отобрать гады?)
Да. немного замарочаный установщик. выбора вариантов нет. создал два раздела, ufs и swap. нажал на финиш. установил но только почемуто оно установилось непонятно куда. загрузка и получаем grub-rescue...
собранный clang не гоняли еще, а так уже месяца два работает на NAS - ведет себя намного лучше чем 8.х
а чем лучше? В разрезе именно НАСа? А то думаю - стоит ли свои апгрейдить или нусть пока под 8 работают
у нас 8.х рандомно бутался с периодом 1час-7 дней.
Тут допилили isr и поисправляли баги в netgraph (летом 2011). С дополнительным патчем на параллельную обработку пакетов становится счастьем даже с em сетевушками на pppoe
вот с этого места можно поподробнее, плз ?
или ссылку киньте где почитать.
снкс.
ps. сейчас один из НАСов на 8.* держит более 1500к ппое соединений (+ шейпера на нем же) и прожевывает порядка гига в каждую сторону (900к ппс суммарно в ЧНН) на сетевых PT. вот просто интересно можно ЕЩЕ что-то выжать ?
http://pastebin.com/L6jehTCX
взят с форума нага, автора не помню.
к сожалению, не доделан до конца, все никак руки не дойдут, но даже в этом состоянии работает отлично.
если у вас нет проблем с разделением по ядрам нагрузки, то вам это ничем не поможет
Если НАС уже молотит гиг, то куда Вы собрались выжимать больше?
Тут самое время делать из него 2 НАСа.
так их и так два.
просто вот подумалось... знаете - всегда хочется еще лучше, хотя понимаешь, что лучшее враг хорошего...
вот будем делать самосборный третий на i2500k как тут на форуме советовали.
может на нем поэкспериментировать...
tivi
У вас какая конфигурация АС?
NAS ?
Supermicro 5026T-TB + 1xCore i7-980X + 8gb ddr3 (избыточно) + двухпортовый ET.
А, ну нагрузка у Вас в районе 10% наверное.
Шейпер на netgraph или ipfw?
даминет.
нагрузка (pppoe) на одно ядро под 90%. но это из-за объема трафика - практически прямая зависимость.
остальные - не больше 3-5%.
почему и интересовался по поводу распараллеливания нагрузки на ядра в 9-ке для pppoe (без участия дров от яндекса).
А что в 9ке в loader.conf sysctl.conf ?
tivi
Ну с такими нагрузками на ЦП думаю действительно распаралеливание Вам будет в пору.
У меня аналогичная ситуация(1600 онлайн), аналогичные характеристики по всему, только транзитных 2 сетевых в lagg'е (1,2 Гб/с в пике) + яндекс-дрова.
Таким образом добился использования 4 ядер (в районе 30-40%).
Шейпер netgraph(модуль ng_car).
http://pastebin.com/mXVQpfdx
и
http://pastebin.com/iFG4A0BQ
соответственно
Кстати а в чем сущность net.isr.bindthreads?
привязка потоков isr к ядрам процессора. или в свободном плавании на усмотрение планировщика
Хм. Понаблюдал малость - вроде igb:que висят все восемь штук на своих ядрах, особо не мигрируя между ними. В любом случае пихнул для профилактики в лодер.конф на будущее. Спасибо.
Интересно.. а net.isr.direct что стоит?
net.isr.direct и net.isr.direct_force в FBSD9 получили статус устаревших.
вместо этого sysctl введен новый: net.isr.dispatch: deferred
спасибо. на счет loader.conf
hw.igb.max_unterrupt_rate=32000
hw.em.max_unterrupt_rate=32000
наверное interrupt_rate ?
да и у меня стоит карта PT но почему-то:
# sysctl -a|grep interrupt_rate
hw.igb.max_interrupt_rate: 8000
нету под hw.em этого значения...
оно может быть только в некоторых версиях драйвера, может не быть видно после загрузки системы, может не существовать для конкретной модели вашей карты.
я не углублялся в анализ этого, задачей было составить максимально полный универсальный конфиг.
На официаьном сайте все нововведения описаны.
Кстати ahci в ядре по умолчанию, это хорошо, но это не значит, что в 8-ке его нельзя было туда добавить. Драйвера новые с новыми глюками, строгий синтаксис /etc/rc.conf, иллюзия на систему органичения доступом к ресурсам racct. Xen как не было, так и нет, хотя libvirt появилась...
в продолжении темы...
продолжаем оптимизировать 8.2
На сервере доступа упрощенно два интерфейса: igb0 - получаем канал и igb1 - отдаем по PPPoE.
т.к. PPPoE не паралелится по нескольким ядрам штатными средствами, то разумеется igb1 садится на первое (нулевое) ядро и выкушивает его под чистую.
и это не было бы большой проблемой, если бы на это же ядро не садились очереди от igb0 (которая садится на все ядра).
так вот вопрос - как сделать, что бы igb0 "лочилась" на все ядра кроме 0-го или начиная с 1-го и дальше ?
так?
первое и так включено, а второе - указываем какое максимальное кол-во ядер будем использовать.
а мне нужно, что бы использовало "все, кроме 0-го".
спасибо.
Перенесите irq и isr на другие ядра с помощью cpuset.
та же проблема возникла, посоветуйте лекарство.
cpuset
это не то., разбито всё. Еще варианты есть?
Вы должны войти