Перейти до

Вопрос по FreeBSD


Рекомендованные сообщения

Доброго времени суток постояльцам Локала.

 

Есть сервер на FreeBSD 6. Сервер - это конечно громко сказано... обычный десктопный тазик.

В том тазике стоит одноядерный проц Intel celeron D, на данный момент возникла необходимость заменить проц на что-то по мощнее, был выбран Core 2 Duo E8200. 

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

 

FreeBSD 6.4-RELEASE-p7 FreeBSD 6.4-RELEASE-p7

ядро i386 generic

Ссылка на сообщение
Поделиться на других сайтах

проверьте в /usr/src/sys/i386/conf/GENERIC

не закоментировано ли:

options         SMP                     # Symmetric MultiProcessor Kernel

Ссылка на сообщение
Поделиться на других сайтах

По дефолту в 6-ке на i386 SMP нету в GENERIC, есть отдельно SMP, в который собственно цепляется GENERIC. Независимо от наличия работать система все-равно будет. Но на одном коне.

Ссылка на сообщение
Поделиться на других сайтах

ядро пересоберите с поддержкой SMP, выше уже показали где настраивается.

просто пересоберите -- будут работать два ядра

иначе -- одно

 

 

 

	Перекомпиляция/пересобирание ядра/kernel FreeBSD		 
Рано или поздно (скорее всего рано  ) вам понадобится изменить ядро системы. Например включить ipfw, или просто почистить от ненужного мусора. Существует мнение, что это сложно и опасно. Ничего подобного! И Вы в этом сейчас убедитесь... 
Рассмотрим весь процесс пересборки ядра:

1. Стандартный файл ядра, с которым устанавливается система, и который содержит настройки, рассчитанные на загрузку ОС, в большинстве конфигураций находится здесь: /sys/i386/conf/GENERIC. Это файл не надо править НИ ПРИ КАКИХ СИТУАЦИЯХ. Для нового ядра нужно скопировать GENERIC в туже папку под другим названием (в моем случае /sys/i386/conf/NEWKERNEL).

2. Теперь давайте его отредактируем, включив IPFW (для примера). Вы можете использовать любой редактор текстовых файлов, который вам больше нравится. Я предпочитаю "edit".

#edit /sys/i386/conf/NEWKERNEL

Первое, что надо изменить это параметр "ident GENERIC" на "ident NEWKERNEL" (в моем случае). Именно по этому параметру компилятор будет находить требуемый для компиляции конфиг ядра, а не по названию файла и вполне логично делать их одинаковыми (ident и имя файла).

Все изменения (кроме закомментирования ненужного оборудования) я делаю в самом конце файла. И вам советую поступать так же, не будет долгих поисков "И где же я тут правил?". Добавим в конец файла следующие строки:

options IPFIREWALL # включаем поддержку ipfw на уровне ядра
 options IPDIVERT # включаем поддержку перенаправления пакетов (нужно для NATD)

Вышли с сохранением изменений. Конфиг для компиляции ядра с поддержкой ipfw готов.

3. Сборка и установка нового ядра.

переходим в каталог /usr/src/: "# cd /usr/src/"
 собираем ядро: "# make BUILDKERNEL KERNCONF=NEWKERNEL" вместо NEWKERNEL должен стоять ident вашего конфига
 устанавливаем ядро: "# make INSTALLKERNEL KERNCONF=NEWKERNEL" вместо NEWKERNEL должен стоять ident вашего конфига 

Если при выполнении сборки выдана ошибка и сборка остановлена, значит вы допустили ошибки в конфиге. Понятно что их нужно исправить  И будьте осторожны! Если Вы работаете на удаленной машине, не трогайте сетевые настройки, и не включайте ipfw в закрытый режим, не проверив работоспособность его конфигурации на другой машине. 

Все! Осталось только перезагрузиться: "shutdown -r now"
P.S. Если у вас машина не однопроцессорная то вам следует компилировать ядро SMP от GENERIC отличается одной строчкой!

 

Відредаговано andytg
Ссылка на сообщение
Поделиться на других сайтах

Не стоит ничего делать, лучше поставить новый процессор, а потом думать. Я точно не помню, но по-моему в 6.4 i386 уже GENERIC с SMP был собран

Ссылка на сообщение
Поделиться на других сайтах

Не стоит ничего делать, лучше поставить новый процессор, а потом думать. Я точно не помню, но по-моему в 6.4 i386 уже GENERIC с SMP был собран

или 6.2 или 6.3 у меня уже летала на ноуте с двухядерным процессором.

5.5 еще не.

Відредаговано andytg
Ссылка на сообщение
Поделиться на других сайтах

 

 

Я точно не помню, но по-моему в 6.4 i386 уже GENERIC с SMP был собран

Нет. Есть на 6.4 GENERIC и есть SMP - два разных конфига для сборки. Последний тупо инклудит первый. Но не наоборот.

Ссылка на сообщение
Поделиться на других сайтах

как поведет себя система, когда ей подсунут многоядерный проц в место одноядерного

 

запустится и будет работать

но ядро пересобрать с SMP все же стоит

Ссылка на сообщение
Поделиться на других сайтах

Всем отозвавшимся спасибо.

Получу новый проц, и тогда буду пробовать!

Скорее всего придется пересобирать ядро, так как о SMP в конфиге ядра ни слова...

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

    • Від a_n_h
      Всем доброго дня и мирного неба!
        После многочисленных экспериментов выяснил, что на последних версиях freebsd  максимум удавалось прокачать до 14 ГБт суммарно трафика со 100% загрузкой процессора. На том-же железе но с установленной freebsd 11.2 прокачивается до 20-ти ГБт суммарно тестового трафика с загрузкой процессора около 50%. 
        Подскажите, что можно убрать или наоборот добавить в систему с freebsd 13,3 для получения аналогичного результата...
    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • Від FantoM_EscapE
      Хочу перенести свій білінг NODENY із фізичного сервера на віртуальний. Шукаю адміна який зможе допомогти у цьому питанні, так як нашого адміна банально призвали до війська. Вся схема на даний момент робоча, маю доступи до всього. Потрібно проінсталити на новішу версію FREEBSD, бо на моїй 10 річній вже не працюють нові SSL сертифікати. Кого зацікавила дана пропозиція - прошу у приватні повідомлення. обсудимо ціну і строки. або пишіть на будь-який месенджер 0677792091
    • Від rusol
      Добрый вечер.
       
      Есть от провайдера блок реальных адресов, к примеру 100.1.1.192/26
       
      Раньше сеть была в одном влане и записи в /etc/rc.conf были такие:

       
      ifconfig_ix0="inet 192.168.0.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP ifconfig_ix0_alias0="inet 100.1.1.193 netmask 255.255.255.192" # Шлюз для пользователей с реальными IP  
      После чего стала задача часть пользователей переводить во вланы тоже с разделением на локальные IP и реальные, первый влан создал где-то пару лет назад и все работает:
       
      ifconfig_vlan1="vlan 1 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 1 ifconfig_vlan1_alias0="inet 100.1.1.248 netmask 255.255.255.248" # Шлюз для пользователей с реальными IP  во Влане 1  
      И вот стоит задача создать еще один влан, делаю по аналогии с вланом 1, только маску смещаю назад:
       
      ifconfig_vlan2="vlan 2 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 2 ifconfig_vlan2_alias0="inet 100.1.1.246 netmask 255.255.255.254" # Шлюз для пользователей с реальными IP во Влане 2  
      Когда я внес это в /etc/rc.conf и прописал команду:
       
      ifconfig vlan2 create  
      Все заработало.
       
      Но как только перезагрузился сервер, перестали работать реальные IP без вланов, в первом влане и во втором. Не пойму что не так делаю, возможно я с маской подсети что-то недопонимаю...
×
×
  • Створити нове...