Тестирования Apache,PHP, MySQL на FreeBSD/Linux/Solaris

> Не берусь утверждать с полной уверенностью, но дебаг инфо не должна замедлиать работу программы.

не берись. Дебаг сильно меняет генерируемый код, дабы "дебаг инфо" была осмысленной. Банальный пример - 10 миллионов вычислений числа фиббоначи от 40.

fib2.debug - собран с -g, fib2.opt - собран с -O3

fib2.debug > /dev/null 8,16s user 0,05s system 93% cpu 8,767 total

fib2.opt > /dev/null 6,13s user 0,04s system 91% cpu 6,745 total

еще смешнее. сравнивают код -O3 с кодом без -Ox. поздравляю, господин соврамши.

Чувак, ты какой-то странный...

r00t@r00t:~$ gcc newtest.c -lm -o ./newtest
r00t@r00t:~$ ls ./newtest -s
16 ./newtest*
r00t@r00t:~$ time ./newtest

real 0m52.169s
user 0m50.710s
sys 0m0.000s
r00t@r00t:~$ gcc newtest.c -g -lm -o ./newtest
r00t@r00t:~$ ls ./newtest -s
24 ./newtest*
r00t@r00t:~$ time ./newtest

real 0m52.805s
user 0m50.740s
sys 0m0.000s

Еще вопросы будут, наверное... И рассказы про "в некоторых случаях".
"-g" здесь, конечно, 10% тормозов не показал, но и дисковых операций небыло.

Это еще раз подверждает что "трындеть мы все горазды" :)

+5

> Еще вопросы будут, наверное... И рассказы про "в некоторых случаях". > "-g" здесь, конечно, 10% тормозов не показал, но и дисковых операций > небыло.

и что ты показал?

что debuginfo файлу прибавляет объема? так даже если эта хрень и висит в памяти (тогда ядро очень тупое), то загрузка происходит один раз.

0m52.169s vs 0m52.805s ? в пределах погрешности. дисковые операции не обязательны, достаточно того, что debuginfo - это +несколько дополнильных секций в elf, которые надо обработать в момент запуска.

>Добавление дебагинфо в любом случае подразумевает падение производительности.

Хм ... Неочевидно. Из info gcc

Unlike most other C compilers, GCC allows you to use `-g' with `-O'. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.

Т.е. -g при -O НЕ ВЛИЯЕТ на оптимизацию кода. Единственно на что -g может влиять, так это на -fomit-frame-pointer - т.е. скорее всего фрейм генерится.

>Попросту потому, что нужно иметь некоторое количество ОЗУ для сохранения дебагинфо и дополнительное место в ОЗУ на собственно сам код дебагинфо

Слова человека АБСОЛЮТНО невладеющего темой. DEBUGINFO ОЗУ НЕ КУШАЕТ ИБО В ПАМЯТЬ НЕ ГРУЗИТСЯ!

>нужно выполнять излишние обращения к ОЗУ на предмет сохранения состояния

Ха-ха-ха!!! Афтар пеши еще! Давно так не смеялся!

>нужно в конце-концов выполнять дополнительный к непосредственно с амому коду приложения код дебагинфо

Мда! И нестыдно такое писать? Это уже не смешно.

Чувак, с тобой вообще я не знаю о чем разговаривать можно...
Ты умудрился так "потюнить" этот сервер, что он в пике у тебя показывает весьма так себе средненькую производительность, причем независимо от ОС. Мы тут всем IT отделом угораем и прямо гордость берет, что у нас двухголовые Xeon HT с парой гигов оперативки куда как большую производительность показывают...

Вот, например. Заметь, это ФРИХОСТ. На который особо так никто не заморачивается в тюнинге. Причем, сервер американский и основная нагрузка на него ночью по МСК. Аптайм, правда, не блещет - только вчера обновил ядро до 2.6.15.7. На серваке Apache+PHP+ZendOptimizer+IonCube+MySQL.
И заметь - почти 2 гига в свопе. Это из-за очень большого количества дисковых операций. А в твоем тесте дисковых операций после выхода в "боевой режим" (то есть когда вся дата в дисковом кеше в оперативке) кроме как на запись вообще быть не должно!!! А если бы ты был совсем умным мальчиком, ты бы основным табличкам мускля тип heap поставил, чтобы комп лишний раз не дергал винт.

[root@freehost r00t]# ps ax | grep httpd | wc -l
693
[root@акуурщые r00t]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
stepping : 5
cpu MHz : 2400.153
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 4805.98

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
stepping : 5
cpu MHz : 2400.153
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 4800.31

processor : 2
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
stepping : 5
cpu MHz : 2400.153
cache size : 512 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 4800.35

processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
stepping : 5
cpu MHz : 2400.153
cache size : 512 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 4800.41
[root@freehost r00t]# cat /proc/meminfo
MemTotal: 2076020 kB
MemFree: 82904 kB
Buffers: 51232 kB
Cached: 263416 kB
SwapCached: 584244 kB
Active: 1758900 kB
Inactive: 124188 kB
HighTotal: 1179584 kB
HighFree: 1728 kB
LowTotal: 896436 kB
LowFree: 81176 kB
SwapTotal: 4192924 kB
SwapFree: 2361120 kB
Dirty: 2924 kB
Writeback: 0 kB
Mapped: 1575816 kB
Slab: 79716 kB
CommitLimit: 5230932 kB
Committed_AS: 6606232 kB
PageTables: 16116 kB
VmallocTotal: 114680 kB
VmallocUsed: 5492 kB
VmallocChunk: 109052 kB
[root@freehost r00t]# uptime
06:09:19 up 1 day, 40 min, 1 user, load average: 0.72, 1.29, 1.96
[root@freehost r00t]# cat /proc/version
Linux version 2.6.15.7madebyR00T (root@freehost) (gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)) #1 SMP Thu Mar 30 05:10:04 EST 2006

ROOT, хорош флудить, ты уже посмешил нас достаточно.

Онанисты на LORе - самые известные жывотные в Рунете после бобруйчан.

>DEBUGINFO ОЗУ НЕ КУШАЕТ ИБО В ПАМЯТЬ НЕ ГРУЗИТСЯ
Ага. Дата из бинарника прямо с диска в регистры процессора приходит.

>Ха-ха-ха!!! Афтар пеши еще! Давно так не смеялся!
Это ты меня до слез смешишь. Ну увеличился при -g бинарник в 1.5 раза - эка невидать. И прога-то математическая. Всякие libICE-чего-нибудь.so в 4 раза меньше становятся - фигня... В общем, Онанист, с твоим подходом к теме, шел бы ты куда-нибуть прямо, а потом чуть-чуть направо.

ROOT, ты правда идиот? debuginfo не нужно при исполнении, его gdb употребляет. почитай уже бумажку какую-нибудь.

Нет, идиот именно ты.
А разве я говорил, что оно исполняется? Кажется, я говорил, что тратится время на обработку дебагинфо.

буагагага. зачем во время исполнения обрабатывать debuginfo? нужно только соответствующие секции в elf игнорировать при формировании memory map. "код дебагинфо" ... гыгыгы.

>Ага. Дата из бинарника прямо с диска в регистры процессора приходит.

Ксли бы ты не был уродом и не пытался бы выглядеть героем после того, как показал ОЧЕВИДНУЮ и СМЕХОТВОРНУЮ некомпетентность, то я бы рассказал тебе в кратце о том, почему секции debug_info не попадают в озу. Это наверное сейчас каждый первокурсник или даже школьник знает.

>Мы тут всем IT отделом угораем

Этот Отдел похоже "Отдел дома для умственно неполноценных", иначе угорал бы над твоими перлами.

>Нет, идиот именно ты. А разве я говорил, что оно исполняется? Кажется, я говорил, что тратится время на обработку дебагинфо.

Да нет идиот не он, а ТЫ! И к тому же - скользкий тип. Нехрен юлить -

<quote> нужно в конце-концов выполнять дополнительный к непосредственно самому коду приложения код дебагинфо... </quote>

Твоя писанина - обрати внимание на "выполнять ... код дебагинфо". Кем нужно быть, чтобы громогласно вещать такие ПЕРЛЫ и потом еще доказывать свою правоту?

Онанисты, вам ведь было совершенно четко указано идти на йух и оттуда не возвращаться. Чего снова-то приперлись?

> Онанисты, вам ведь было совершенно четко указано идти на йух и оттуда не возвращаться. Чего снова-то приперлись?


R00T ты в очередной раз обасрался, и ещё какашками кидаешься, придурок :)

Ты достал уже немножко.

Или ини на ж. или приведи более веские аргументы чем @Этот Отдел похоже "Отдел дома для умственно неполноценных"@

позорище!!!!! где факты? о чём ваш спор? почему на личности переходите? если нечего сказать, то помолчите. почитайте каменты от 2002 и ниже годов - поймёте, какой раньше грамонтый люд сидел тут. Откуда вы взялись? Кто вас до клавы допустил?

по теме: где тюнинг фрибсд? где mbuf и всё вытекающее в ядре? где sysctl и его опции? тест интересен только как "производительность из коробки". у фрибсд, по ходу, и правда проблемы с шедулером, об этом уже где-то писалось, и не раз.

гыгыгы. у freelsd проблемы не только с шедулером.