Artom_12 Опубликовано 11 ноября, 2018 · Жалоба Приветствую уважаемые! есть у нас сеть на 10к+ абонентов стоит у нас свой DNS сервер (unbaund) кэширующий, т.к. ставили 100 лет назад стоит на x32 Ubuntu, все это на виртуальной машине вопросы : есть ли смысл переделать это все на x64 туже убунту? Будет ли толк? нормально ли это все должно работать из под виртуалки или стоит раскошелится? и если не сложно то оптимальная версия ОС (14, 15,16...) и версия самого анбаунда. Заранее всем спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
murano Опубликовано 11 ноября, 2018 (изменено) · Жалоба 64 бита не влияют на скорость. Эта архитектура лишь снимает ряд ограничений по длине байт хранимых в памяти данных. Т.е. увеличивает в 2 раза их длину и позволяет с ними работать процессору также. Для примера, наступит момент, когда 32 бита перестанут вмещать в себя время, хранимое в секундах в timestamp. Вывод: стоит перейти на х64, т.к. 32 бита уже уходит в небытие. На виртуалке все прекрасно работает. Тут все от кривизны рук и ресурсов гипервизора зависит, которые он может дать виртуалке. Ну и не путайте скорость работы и производительность. На одинаковой скорости можно получить разные объемы обрабатываемых и результирующих данных на выходе Архитектура х64 - это, как раз, объем. Скорость работы совсем от других праметров зависит. И, к тому же, Вы на х32 упретесь в ограничение ОЗУ в 4 ГБ. Всякие там PAE-модификации ядер линукса решают эту проблему, но это переходный костыль для случаев имитации 64 бит на 32 железе. Изменено 11 ноября, 2018 пользователем murano Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 11 ноября, 2018 (изменено) · Жалоба 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%. Изменено 11 ноября, 2018 пользователем rm_ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
grifin.ru Опубликовано 11 ноября, 2018 · Жалоба Я не вижу что бы автор жаловался на производительность. ИМХО ДНС то настолько низкотребовательный к ресурсам сервис, что его можно на малинке крутить при правильной настройке ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 11 ноября, 2018 · Жалоба Если скучно - переходите Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ipaddr.ru Опубликовано 11 ноября, 2018 · Жалоба Мониторинг для начала настройте. Сколько kqps соберёте? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 11 ноября, 2018 · Жалоба сразу видно, что ТС страдает от скуки. Проблем нет, но хочется что-нибудь поделать По существу: менять 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-сервера на фоне обработки строковых данных Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 11 ноября, 2018 · Жалоба Может и не от скуки. Держать только х64 - уменьшить зоопарк и повысить секурность, ибо многие фишки ОС для х32 не работают в принципе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 11 ноября, 2018 · Жалоба 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% быстрее, как я и предположил выше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
murano Опубликовано 12 ноября, 2018 · Жалоба 8 часов назад, s.lobanov сказал: ещё есть особые случаи типа php5 (может и php7, не знаю), где int зависит от разрядности системы, что доставляет массу приколов А что, бывает где-то, что не зависит? В х64 объем памяти под любые типы в 2 раза увеличивается. Нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 ноября, 2018 · Жалоба 7 часов назад, murano сказал: А что, бывает где-то, что не зависит? В х64 объем памяти под любые типы в 2 раза увеличивается. Нет? Нет. У тебя как была картинка 100кб в жпеге так она и останется. Указатели и код распухают, но это не приводит к двухкратному росту потребления памяти, потому что далеко не все обрабатываемые данные зависят от типа платформы. А если говорить за конкретно типа данных, то есть всякие uint8_t, uint16_t, uint32_t, uint64_t, uint128_t - которым пофик на железо, иначе бы у тебя банально диск нельзя было примонтировать и пакеты по сети далеко не всеми принимались бы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 ноября, 2018 · Жалоба 15 часов назад, murano сказал: А что, бывает где-то, что не зависит? В х64 объем памяти под любые типы в 2 раза увеличивается. Нет? да даже в C. если вы возьмете gcc одной и той же версии для i386 и x86_64, и посмотрите sizeof(int), то оно будет одинаково (обычно, 4). но поскольку никаких стандартом (ну или большинством стандартов) это не гарантируется, то используют sizeof(int) чтобы узнать размерность int в коде Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 ноября, 2018 · Жалоба В 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 кеши не бесплатна Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 13 ноября, 2018 · Жалоба В 12.11.2018 в 01:52, rm_ сказал: Всё быстрее, что не помещается в старые 8 регистров Угу, точно так. И во столько-же раз больше размер сохраненного контекста при смене активной задачи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 14 ноября, 2018 · Жалоба В 13.11.2018 в 09:26, snvoronkov сказал: Угу, точно так. И во столько-же раз больше размер сохраненного контекста при смене активной задачи. Дык, имнип из программирования помнится, что передаётся только ссылка на контекст, точнее адрес памяти. Если память не ограничена(огромна) то ссылки на кусочки огромной памяти через охрененные регистры проца нормально быстро обработаются при смене контекста. Причем всё в системе должно быть одной разрядности, без костылей 32/64, для приложений особенно. Принимал участие в костыллинге 16/32. Ну и при кривоватости древней ос-рв тоже был, там было мрачнее но понятнее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 15 ноября, 2018 · Жалоба 19 часов назад, YuryD сказал: Дык, имнип из программирования помнится, что передаётся только ссылка на контекст, точнее адрес памяти. Не про то. При смене процесса/прерывании больше регистров в ОЗУ скидывать и потом оттуда восстанавливать, причем еще и большей разрядности. А ОЗУ- оно мееедленное, по сравнению с регистрами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 15 ноября, 2018 · Жалоба 3 часа назад, snvoronkov сказал: При смене процесса/прерывании больше регистров в ОЗУ скидывать и потом оттуда восстанавливать, причем еще и большей разрядности. Так в сетевухах есть отложенные прерывания, ядро тюнится через HZ чтобы процессы не переключались часто и тп. Расширенные регистры (SSE/AXV) в ядре не юзаются что сокращает контекст. В пользовательских приложениях там есть оптимизация в виде флага что они юзаеются, и есть специальная ком*** для обнуления этого флага и регистров чтобы они не сохранялись. При этом профит много где по скорости х2, а переключение контекста и даже просто его сохранение при вызове функции внутри программы не настолько большой чтобы всё изгадить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 16 ноября, 2018 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 16 ноября, 2018 · Жалоба 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 ядер, получится совсем ничего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 16 ноября, 2018 · Жалоба В 15.11.2018 в 14:06, snvoronkov сказал: Не про то. При смене процесса/прерывании больше регистров в ОЗУ скидывать и потом оттуда восстанавливать, причем еще и большей разрядности. Память тормозит не столько на объеме записи/чтения сколько от количества операций. Сложить одной операцией в 2 раза больше регистров (а там не килобайты же) не заметно медленнее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 18 ноября, 2018 · Жалоба В 17.11.2018 в 02:28, Tosha сказал: Память тормозит не столько на объеме записи/чтения сколько от количества операций. Сложить одной операцией в 2 раза больше регистров (а там не килобайты же) не заметно медленнее. 32 байта vs. 128 байт. Чем меньше, тем выше шанс, что оно в кэше осядет и вытесниться в память тупо не успеет. Вобщем, это я вообще к чему? Не всегда x64 лучше чем x32. Есть как несомненные плюсы, так и минусы. В 16.11.2018 в 21:47, Ivan_83 сказал: Считать научись ~ 5178. Потом у тебя странный таймер, пора уже свалить на HPET, он генерирует прерывания один и только когда это нужно. Тем не менее, всего на систему именно >40000 прерываний генерируется. И регистровый контекст их всех лезет в кэш двух процессоров (тут - два по 4-е ядра). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 18 ноября, 2018 · Жалоба Коллеги, обсуждая пенальти при переключении контекста не забывайте, что основная катастрофа не в сохранении состояния регистров процессора. Основная проблема в сбросе конвеера и частичной очистке кеша (Спектр и Мелтдаун). Переключение контекста на x86 эквивалентно пенальти размером от 1000 до 100000 операций процессора смотря по обстоятельствам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 21 ноября, 2018 · Жалоба В 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 режиме конечно не все пространство памяти было "видно". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 27 ноября, 2018 · Жалоба В 18.11.2018 в 19:18, sol сказал: Коллеги, обсуждая пенальти при переключении контекста не забывайте, что основная катастрофа не в сохранении состояния регистров процессора. Основная проблема в сбросе конвеера и частичной очистке кеша (Спектр и Мелтдаун). Переключение контекста на x86 эквивалентно пенальти размером от 1000 до 100000 операций процессора смотря по обстоятельствам. И ничего что главный пингвиноид сказал, нахер вам эти чистки кэша, мельедаун и спектр ? чего мы будем париться, что вдруг память чужого контекста вдруг будет доступна иным приложениям, вы сначала туда в ринг0 попадите.... Пользовательский контекст - да насрать на него, чего вы там поймаете ? А снижение производительности серверов в 10 раз - сразу почуете. Один из моих ч***ков невежественных - сразу прибежал с гордой вестью, он нашел, что если патч от мелкосовта удалить то сурово убыстрился его домашний комп :). Про переключение контекста, предыдущие значения регистров кладутся в стек, если в x86 что-то изменилось. И извлекаются из стека легко. Конечно хуже, чем у pdp11 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 27 ноября, 2018 · Жалоба 7 минут назад, YuryD сказал: Про переключение контекста, предыдущие значения регистров кладутся в стек, если в x86 что-то изменилось. И извлекаются из стека легко. Конечно хуже, чем у pdp11 Так, да не так. Положить регистры, а их сильно дохера, в стек не сложно. Сложность начинается в деталях. При переключении контекста меняется "поток команд". Иными словами, процессор спокойно выполнял один программный код, и тут БАЦ! Надо выполнять другой. Конвеер длинной порядка 100 стадий надо чистить, всё спекулятивное выполнение, которое навыполнялось, надо похерить, MMU перепрограммировать на новые маппинги памяти и разогревать всю эту канитель новым программным кодом. Вот это и есть основное пенальти при переключении контекста. А сейв регистров это так, детский лепет. Хотя, в RISC процессорах и этого делать не надо. Там регистровый файл. Окошко передвинул и всё. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...