Поддержка мультипроцессорности

[Jetro]

Такой вот вопрос - как сейчас обстоят дела с мультипроцессорностью в последних версиях FreeBSD? Интересуют версии 8.1 и 8.2.
Когда-то давно читал что нужно пересобирать ядро для включения поддержки, но это было времен FreeBSD 5-6 версий.
Сейчас играюсь со стареньким сервером на Туалатинах. Установлена FreeBSD 8.2 i386. Она вроди и видит оба процессора, но как-то не так как надо, такое впечатление что система второй проц хоть и видит, но использовать не хочет. Вот только что закончил выполняться тяжелый скрипт на Перле, топ говорил что он загружал около 49% процессорных ресурсов, около 1% загружали остальные процессы, а вот простой был всегда ровно 50%.
"dmesg | grep -i cpu" говорит следующее:

Код: Выделить всё

CPU: Intel(R) Pentium(R) III CPU family      1266MHz (1266.07-MHz 686-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
SMP: AP CPU #1 Launched!

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[iZEN]

Подсистема интерпретатора Perl с отпцией WITH_THREADS=true собрана?

По умолчанию perl собирается без поддержки мультипроцессорности:

Код: Выделить всё

> pkg_info -Ex perl
perl-5.14.2

> cat /var/db/ports/perl/options 
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for perl-5.14.2
_OPTIONS_READ=perl-5.14.2
WITHOUT_DEBUGGING=true
WITHOUT_GDBM=true
WITHOUT_PERL_MALLOC=true
WITH_PERL_64BITINT=true
WITHOUT_THREADS=true
WITHOUT_MULTIPLICITY=true
WITHOUT_SITECUSTOMIZE=true
WITH_USE_PERL=true

Если perl пересобрать с опцией WITH_THREADS=true, то пакет perl будет называться perl-threaded-5.14.2.tbz

[Jetro]

Собрана:

Код: Выделить всё

# cat /var/db/ports/perl/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for perl-5.12.4_3
_OPTIONS_READ=perl-5.12.4_3
WITHOUT_DEBUGGING=true
WITHOUT_GDBM=true
WITHOUT_PERL_MALLOC=true
WITH_PERL_64BITINT=true
WITH_THREADS=true
WITH_MULTIPLICITY=true
WITHOUT_SITECUSTOMIZE=true
WITH_USE_PERL=true

Вообще странно все это:
Посмотрел конфиг Generic - в нем SMP по дефолту подключено. Потом обратил внимание на то что в top есть строка "С", которая похоже показывает какой из процессоров использует тот или иной процесс. У меня возникло чувство что процессы в Фре не используют оба процессора одновременно, а берут под себя только один. Сейчас вот ядро пересобираю - загрузка снова-же около 50%, но иногда опускается до 47-48%, и эти 2-3% загружают другие запущенные процессы, а не компиляция ядра. Очень странно...

[BirdGovorun]

make -j4 при сборке ядра и посмотрите
man make

[Alex Keda]

У меня возникло чувство что процессы в Фре не используют оба процессора одновременно, а берут под себя только один. Сейчас вот ядро пересобираю - загрузка снова-же около 50%, но иногда опускается до 47-48%, и эти 2-3% загружают другие запущенные процессы, а не компиляция ядра. Очень странно...

вы не очень понимаете теорию, помоему.

вообще, многопроцессорность - это не только собенность ОС, но и приложений
если приложение не умеет использовать более одного процессора - то на два и более его не размажет ни одна ОС

и дайте вывод top, минут через 30 после начала выполнения команы которую вам дал Adre

dmesg полный не помешал бы...

[iZEN]

Шапку вывода "top -P" сюда.

[Jetro]

вы не очень понимаете теорию, помоему.

вообще, многопроцессорность - это не только собенность ОС, но и приложений
если приложение не умеет использовать более одного процессора - то на два и более его не размажет ни одна ОС

Не могу назвать себя гуру, но тем не менее кое-какие знания все-же имеются.
С многопроцессорными системами раньше работать не приходилось, по этому и решил посмотреть как там себя оба процессора ведут - увиденное не обрадовало.
О том, что ни одна операционка не способна заставить однопоточное приложение использовать два процессора я знаю, но ведь здесь, в моем случае, все что я устанавливал, я собирал с поддержкой многопоточности, тот самый перл собран с WITH_THREADS=true, но при этом он использовал всего одно ядро, вот я и подумал что FreeBSD не умеет работать с несколькими процессорами, и поднял панику

При первой сборке ядра "-j4" я прописывал в make.conf, но оттуда он почему-то не подхватился. Когда прописал ключ напрямую при сборке, то она действительно начала использовать оба процессора.
Короче говоря - все работает как нужно, это я поспешил с выводами. Всем спасибо за помощь.
Очередной раз я доказал себе что мне еще учиться и учиться...

[nops]

Я немного не понял, а как итог, что именно нужно пересобрать с ключем -j4, Ядро FreeBSD или же сам perl?
Perl устанавливал из портов, ставил ВСЕ, но компилировал make && make install && rehash

[nops]

Я немного не понял, а как итог, что именно нужно пересобрать с ключем -j4, Ядро FreeBSD или же сам perl?
Perl устанавливал из портов, ставил ВСЕ, но компилировал make && make install && rehash
По факту же у меня вот такая канитель сейчас:

last pid: 65054; load averages: 1.05, 1.11, 0.99 up 2+14:47:05 10:31:02
272 processes: 2 running, 270 sleeping
CPU 0: 67.4% user, 0.0% nice, 2.2% system, 0.0% interrupt, 30.3% idle
CPU 1: 23.3% user, 0.0% nice, 1.1% system, 0.4% interrupt, 75.2% idle
CPU 2: 16.9% user, 0.0% nice, 0.0% system, 1.1% interrupt, 82.0% idle
CPU 3: 1.9% user, 0.0% nice, 1.5% system, 0.4% interrupt, 96.2% idle
Mem: 1380M Active, 1668M Inact, 701M Wired, 68M Cache, 415M Buf, 93M Free
Swap: 4096M Total, 2268K Used, 4094M Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
62122 root 1 118 0 68140K 55152K CPU1 1 30:59 100.00% perl5.16.2
1452 squid 1 45 0 81912K 20184K kqread 0 71:01 2.88% squid
62130 root 1 44 0 5828K 836K pipewr 0 0:16 0.10% cat

Получается, что у меня система занята на 25%

[Dark_ASU]

Лучше не юзать перл с тредами проблем потом не отгребете

[nops]

Лучше не юзать перл с тредами проблем потом не отгребете

Ну дело в том, что у меня каждые 3 часа запускается парсер squidлогов - lightsquid.pl Он конечно выкушивает 100% но только одного ядра. Этот процесс занимает давольно много времени, узает около 150 человек прокси, ~15Гб трафика в день.
100% - это 25% от всего процессора, а я хотел бы ускорить этот процесс ну как минимум в 2 раза, а лучше в 3. Я хочу чтобы использовались все мощности процессора, а не только мощность одного ядра.

[vadim64]

как часто Вы ротируете этот лог?

[nops]

как часто Вы ротируете этот лог?

Каждые 3 часа
А не, что вы имеете ввиду?
Ротирую или парсю?(что-то я туплю в понедельник)

[vadim64]

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

парсинг логов - не то узкое место, о котором нужно беспокоиться

[nops]

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

парсинг логов - не то узкое место, о котором нужно беспокоиться

Пожалуй я с вами согласен. В общем ротация была выставлена в "ежемесячно", поменял на "еженедельно", надеюсь уменьшится время.
Но это все же настройка сквида, немного не по теме, но спасибо.

[vadim64]

Пожалуй я с вами согласен. В общем ротация была выставлена в "ежемесячно", поменял на "еженедельно", надеюсь уменьшится время.
Но это все же настройка сквида, немного не по теме, но спасибо.

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