[Artom_12]

Приветствую уважаемые!

 

есть у нас сеть на 10к+ абонентов 

стоит у нас свой DNS сервер (unbaund) кэширующий, т.к. ставили 100 лет назад стоит на x32 Ubuntu, все это на виртуальной машине

 

вопросы : есть ли смысл переделать это все на x64 туже убунту? Будет ли толк?

нормально ли это все должно работать из под виртуалки или стоит раскошелится?

 

и если не сложно то оптимальная версия ОС (14, 15,16...) и версия самого анбаунда.

 

Заранее всем спасибо!

[murano]

64 бита не влияют на скорость. Эта архитектура лишь снимает ряд ограничений по длине байт хранимых в памяти данных. Т.е. увеличивает в 2 раза их длину и позволяет с ними работать процессору также. Для примера, наступит момент, когда 32 бита перестанут вмещать в себя время, хранимое в секундах в timestamp. 

 

Вывод: стоит перейти на х64, т.к. 32 бита уже уходит в небытие.

 

На виртуалке все прекрасно работает. Тут все от кривизны рук и ресурсов гипервизора зависит, которые он может дать виртуалке.

 

Ну и не путайте скорость работы и производительность. На одинаковой скорости можно получить разные объемы обрабатываемых и результирующих данных на выходе 

 

Архитектура х64 - это, как раз, объем. Скорость работы совсем от других праметров зависит. И, к тому же, Вы на х32 упретесь в ограничение ОЗУ в 4 ГБ. Всякие там PAE-модификации ядер линукса решают эту проблему, но это переходный костыль для случаев имитации 64 бит на 32 железе.

 

Edited November 11, 2018 by murano

[rm_]

17 minutes ago, murano said:

 

64 бита не влияют на скорость

На других архитектурах нет, а на x86 влияет, поскольку одновременно со всем этим удваивает количество доступных регистров общего назначения в процессоре.

И сами регистры вдвое больше, т.е. например IPv6-адрес можно обработать за две операции, а не за четыре.

https://en.wikipedia.org/wiki/X86-64#Architectural_features первые три пункта

ну и Instruction pointer relative data access тоже полезно.

Переходить можно, хуже не будет.

Но и сильно лучше на задаче DNS-сервера тоже вряд ли, думаю максимум +5-10%.

 

 

Edited November 11, 2018 by rm_

[grifin.ru]

Я не вижу что бы автор жаловался на производительность. ИМХО ДНС то настолько низкотребовательный к ресурсам сервис, что его можно на малинке крутить при правильной настройке )

[SyJet]

Если скучно - переходите 

[ipaddr.ru]

Мониторинг для начала настройте. Сколько kqps соберёте?

[s.lobanov]

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

 

По существу: менять x86 32-бит на x86_64 имеет лишь в том случае, когда вендор дропает поддерджку x86 (это сейчас довольно популярно делать) или требуется работа с большими объёмами данными без костыля в виде pae. ещё есть особые случаи типа php5 (может и php7, не знаю), где int зависит от разрядности системы, что доставляет массу приколов при попытке запустить код на i386, заточенный под 64-битный

Однако, ubuntu 18.04 LTS, что бы про неё не говорили, официально поддерживает архитектуру i386 (https://help.ubuntu.com/community/Installation/MinimalCD#A32-bit_PC_.28i386.2C_x86.29 ). Единственное что сделали, так это дропнули графический инсталлятор

 

https://packages.ubuntu.com/bionic/unbound - всё тут нормально про i386

 

А про ускорение для ipv6 - ну это всё глупости в разрезе dns-сервера на фоне обработки строковых данных

[Ivan_83]

Может и не от скуки.

Держать только х64 - уменьшить зоопарк и повысить секурность, ибо многие фишки ОС для х32 не работают в принципе.

[rm_]

 

19 minutes ago, s.lobanov said:

А про ускорение для ipv6 - ну это всё глупости в разрезе dns-сервера на фоне обработки строковых данных

Про IPv6 это был всего лишь пример. Всё быстрее, что не помещается в старые 8 регистров или в 32 бита за операцию.

Компиляция быстрее вдвое, как тебе такое #илонмаск? https://www.phoronix.com/scan.php?page=article&item=ubuntu-1710-x8664&num=2

Из того что ближе всего к нагрузке DNS-сервера, среди всех тестов наверное Апач. Ну на 10% быстрее, как я и предположил выше.

[murano]

8 часов назад, s.lobanov сказал:

ещё есть особые случаи типа php5 (может и php7, не знаю), где int зависит от разрядности системы, что доставляет массу приколов

А что, бывает где-то, что не зависит? В х64 объем памяти под любые типы в 2 раза увеличивается. Нет?

[Ivan_83]

7 часов назад, murano сказал:

А что, бывает где-то, что не зависит? В х64 объем памяти под любые типы в 2 раза увеличивается. Нет?

Нет.

У тебя как была картинка 100кб в жпеге так она и останется.

Указатели и код распухают, но это не приводит к двухкратному росту потребления памяти, потому что далеко не все обрабатываемые данные зависят от типа платформы.

А если говорить за конкретно типа данных, то есть всякие uint8_t, uint16_t, uint32_t, uint64_t, uint128_t - которым пофик на железо, иначе бы у тебя банально диск нельзя было примонтировать и пакеты по сети далеко не всеми принимались бы.

[s.lobanov]

15 часов назад, murano сказал:

А что, бывает где-то, что не зависит? В х64 объем памяти под любые типы в 2 раза увеличивается. Нет?

да даже в C. если вы возьмете gcc одной и той же версии для i386 и x86_64, и посмотрите sizeof(int), то оно будет одинаково (обычно, 4). но поскольку никаких стандартом (ну или большинством стандартов) это не гарантируется, то используют sizeof(int) чтобы узнать размерность int в коде

[s.lobanov]

В 11/11/2018 в 23:52, rm_ сказал:

 

Про IPv6 это был всего лишь пример. Всё быстрее, что не помещается в старые 8 регистров или в 32 бита за операцию.

Компиляция быстрее вдвое, как тебе такое #илонмаск? https://www.phoronix.com/scan.php?page=article&item=ubuntu-1710-x8664&num=2

Из того что ближе всего к нагрузке DNS-сервера, среди всех тестов наверное Апач. Ну на 10% быстрее, как я и предположил выше.

Ну пока вы админ локалхоста, то можно и поразвлекаться со сменой ОС ради 10%, а в проде работают совершенно другие принципы. Нет, ну есть конечно щас мода на автовыкатывание софта в прод по каждому коммиту в репу, но это всё удел смузихлёбов, которые никогда не работали с чем-то серьёзным в условиях жёстких sla (пусть и внутренних, которые в конечном счете мапятся в qoe конечных пользователей).

 

А если уж заниматься теорией и приводить абстрактные примеры, то существуют примеры когда 64 битный код медленней ввиду того что объём кода больше или например массивы указателей на указтели, а загрузка этого говна из памяти в cpu кеши не бесплатна

[snvoronkov]

В 12.11.2018 в 01:52, rm_ сказал:

Всё быстрее, что не помещается в старые 8 регистров

Угу, точно так. И во столько-же раз больше размер сохраненного контекста при смене активной задачи.

[YuryD]

В 13.11.2018 в 09:26, snvoronkov сказал:

Угу, точно так. И во столько-же раз больше размер сохраненного контекста при смене активной задачи.

 Дык, имнип из программирования помнится, что передаётся только ссылка на контекст, точнее адрес памяти. Если память не ограничена(огромна) то ссылки на кусочки огромной памяти через охрененные регистры проца нормально быстро обработаются при смене контекста. Причем всё в системе должно быть одной разрядности, без костылей 32/64, для приложений особенно. Принимал участие в костыллинге 16/32. Ну и при кривоватости древней ос-рв тоже был, там было мрачнее но понятнее.

[snvoronkov]

19 часов назад, YuryD сказал:

Дык, имнип из программирования помнится, что передаётся только ссылка на контекст, точнее адрес памяти.

Не про то. При смене процесса/прерывании больше регистров в ОЗУ скидывать и потом оттуда восстанавливать, причем еще и большей разрядности.

А ОЗУ- оно мееедленное,  по сравнению с регистрами.

[Ivan_83]

3 часа назад, snvoronkov сказал:

При смене процесса/прерывании больше регистров в ОЗУ скидывать и потом оттуда восстанавливать, причем еще и большей разрядности.

Так в сетевухах есть отложенные прерывания, ядро тюнится через HZ чтобы процессы не переключались часто и тп.

Расширенные регистры (SSE/AXV) в ядре не юзаются что сокращает контекст.

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

При этом профит много где по скорости х2, а переключение контекста и даже просто его сохранение при вызове функции внутри программы не настолько большой чтобы всё изгадить.

[snvoronkov]

15 часов назад, Ivan_83 сказал:

Расширенные регистры (SSE/AXV) в ядре не юзаются что сокращает контекст.

8x32bit vs. 16x64bit

 

И так 41426 раз в секунду. (например, сервант с умеренной сетевой активностью):

Цитата

$ vmstat -i
interrupt                          total       rate
irq28: ciss0                     6586638          0
irq1: atkbd0                          30          0
irq17: atapci0                        58          0
irq20: uhci0 ehci0                     1          0
irq22: uhci2 uhci4                     2          0
irq23: uhci1 uhci3                    12          0
cpu0: timer                  56825903473       1999
irq256: bce0                235050730587       8272
irq257: bce1                168419689106       5927
irq258: bce2                162882821959       5732
irq259: bce3                156125643943       5494
cpu1: timer                  56825893914       1999
cpu5: timer                  56831066080       2000
cpu2: timer                  56825894036       1999
cpu4: timer                  56831066166       2000
cpu3: timer                  56825894415       1999
cpu7: timer                  56831066000       2000
cpu6: timer                  56831066017       2000
Total                      1177113322437      41426

 

[Ivan_83]

9 часов назад, snvoronkov сказал:

И так 41426 раз в секунду. (например, сервант с умеренной сетевой активностью):

Считать научись ~ 5178.

Потом у тебя странный таймер, пора уже свалить на HPET, он генерирует прерывания один и только когда это нужно.

interrupt                          total       rate
irq0: hpet0:t0                 189146108       1683
irq257: xhci0                     798652          7
irq258: ahci0                     359422          3
irq260: xhci1                    1907473         17
irq264: ahci2:ch3                    261          0
irq277: igb0:que 0               4959308         44
irq278: igb0:que 1               3937095         35
irq279: igb0:link                      2          0
irq280: hdac0                     971332          9
irq281: vgapci0                  8150024         73
Total                          210229677       1871

это с моего десктопа и подели на 8 ядер, получится совсем ничего.

[Tosha]

В 15.11.2018 в 14:06, snvoronkov сказал:

Не про то. При смене процесса/прерывании больше регистров в ОЗУ скидывать и потом оттуда восстанавливать, причем еще и большей разрядности.

Память тормозит не столько на объеме записи/чтения сколько от количества операций. Сложить одной операцией в 2 раза больше регистров (а там не килобайты же) не заметно медленнее.

[snvoronkov]

В 17.11.2018 в 02:28, Tosha сказал:

Память тормозит не столько на объеме записи/чтения сколько от количества операций. Сложить одной операцией в 2 раза больше регистров (а там не килобайты же) не заметно медленнее.

32 байта vs. 128 байт. Чем меньше, тем выше шанс, что оно в кэше осядет и вытесниться в память тупо не успеет.

 

Вобщем, это я вообще к чему? Не всегда x64 лучше чем x32. Есть как несомненные плюсы, так и минусы.

 

В 16.11.2018 в 21:47, Ivan_83 сказал:

Считать научись ~ 5178.

Потом у тебя странный таймер, пора уже свалить на HPET, он генерирует прерывания один и только когда это нужно.

Тем не менее, всего на систему именно >40000 прерываний генерируется. И регистровый контекст их всех лезет в кэш двух процессоров (тут - два по 4-е ядра).

[sol]

Коллеги, обсуждая пенальти при переключении контекста не забывайте, что основная катастрофа не в сохранении состояния регистров процессора. Основная проблема в сбросе конвеера и частичной очистке кеша (Спектр и Мелтдаун). Переключение контекста на x86 эквивалентно пенальти размером от 1000 до 100000 операций процессора смотря по обстоятельствам.

 

[Tosha]

В 18.11.2018 в 16:05, snvoronkov сказал:

32 байта vs. 128 байт. Чем меньше, тем выше шанс, что оно в кэше осядет и вытесниться в память тупо не успеет.

кэши процессоров читают минимум строку в 4096 байт даже если читается один байт, да и пишут тоже вплоть до 4096 байт без особых тормозов.
 

В 18.11.2018 в 16:05, snvoronkov сказал:

Не всегда x64 лучше чем x32.

Это да.
 

В 18.11.2018 в 17:18, sol сказал:

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

Количество прерываний и переключений контекста от режима 32/64 не зависит. Это общие грабли дизайна процессора и методов затыкания обнаруженной "дыры"... Хотя в 32 режиме конечно не все пространство памяти было "видно".

[YuryD]

В 18.11.2018 в 19:18, sol сказал:

Коллеги, обсуждая пенальти при переключении контекста не забывайте, что основная катастрофа не в сохранении состояния регистров процессора. Основная проблема в сбросе конвеера и частичной очистке кеша (Спектр и Мелтдаун). Переключение контекста на x86 эквивалентно пенальти размером от 1000 до 100000 операций процессора смотря по обстоятельствам.

 

 И ничего что главный пингвиноид сказал, нахер вам эти чистки кэша, мельедаун и спектр ? чего мы будем париться, что вдруг память чужого контекста вдруг будет доступна иным приложениям, вы сначала туда в ринг0 попадите.... Пользовательский контекст - да насрать на него, чего вы там поймаете ? А снижение производительности серверов в 10 раз - сразу почуете. Один из моих ч***ков невежественных - сразу прибежал с гордой вестью, он нашел, что если патч от мелкосовта  удалить то сурово убыстрился его домашний комп :). Про переключение контекста, предыдущие значения регистров кладутся в стек, если в x86 что-то изменилось. И извлекаются из стека легко. Конечно хуже, чем у pdp11

[sol]

7 минут назад, YuryD сказал:

Про переключение контекста, предыдущие значения регистров кладутся в стек, если в x86 что-то изменилось. И извлекаются из стека легко. Конечно хуже, чем у pdp11

Так, да не так. Положить регистры, а их сильно дохера, в стек не сложно.

 

Сложность начинается в деталях. При переключении контекста меняется "поток команд". Иными словами, процессор спокойно выполнял один программный код, и тут БАЦ! Надо выполнять другой.

Конвеер длинной порядка 100 стадий надо чистить, всё спекулятивное выполнение, которое навыполнялось, надо похерить, MMU перепрограммировать на новые маппинги памяти и разогревать всю эту канитель новым программным кодом.

 

Вот это и есть основное пенальти при переключении контекста. А сейв регистров это так, детский лепет. Хотя, в RISC процессорах и этого делать не надо. Там регистровый файл. Окошко передвинул и всё.