L2TP termination / mpd5 / CPU usage

Vladimir Yesakov написал(а) к All в Feb 15 20:01:01 по местному времени:


Нello everybody!

Может кто-то уже разобрался и подскажет...

Мы недавно объединили наши 4 сервера по 1Gbps в один с 10Gb интерфейсом. Все работает хорошо, но над одной загадкой я уже голову сломал. Почему systat -v и top -SНI показывают ~96% CPU, когда на самом деле температура не поднимается выше 48C ? При такой нагрузке я привык видеть ~70C.

FreeBSD 9.3p10, mpd5.7_1, named 9.10 больше там ничего нет. IPFW/PF/DUMMYNET etc. отключены. ~2500 l2tp сессий. PMC показывает вот такое.
В сервере пара E5-2620/16GB RAM/Intel X520-SR2 (82599EB 10-Gigabit SFI/SFP+ Network Connection)

Google про "mtx_locksleep" ничего внятного не дает, кроме того, что панику в нем починили в районе 7-х версий.

pmcstat -TS instructions -w1
PMC: [INSTRRETIREDANY] Samples: 414587 (100.0%) , 559 unresolved

%SAMP IMAGE FUNCTION CALLERS
28.8 kernel mtx_lock_sleep _mtx_lock_flags:23.3 _sleep:3.9 rtalloc1fib:0.6
9.5 kernel mtx_lock_spin wakeup_one:5.7 _sleep:2.0 pmclog_reserve:1.2 turnstiletrywait:0.5
4.9 kernel cpusearch_lowest cpu_searchlowest
4.3 kernel cpusearch_highest cpu_search_highest:3.7 schedidletd:0.5
3.0 kernel rw_rlock ng_addresshook
2.8 pmcstat _init
2.0 kernel rw_runlock ng_addresshook
1.7 kernel inpcblookup_hash_lo in_pcblookuphash
1.4 kernel rnmatch rtalloc1fib
1.4 netgraph.k ngsnd_item ng_applyitem
1.2 kernel runqsteal tdqmove
1.0 libc.so.7 bsearch
1.0 kernel atomicfetchadd_int ng_unrefhook
0.9 kernel umazallocarg
0.9 kernel ixgbexmit ixgbe_mq_startlocked
0.9 kernel bzero
0.8 kernel ethernh_input netisr_dispatchsrc
0.8 kernel spinlock_exit
0.7 kernel ixgberxeof ixgbe_msixque
0.7 kernel umazfreearg
0.7 named _init
0.7 kernel ip_output
0.7 kernel atomicadd_barr_int ng_addresshook
0.6 kernel critical_exit
0.6 kernel mtx_unlockflags
0.6 kernel bus_dmamap_load_buf _bus_dmamap_load_mbufsg
0.5 kernel critical_enter
0.5 mpd5 _init
0.5 kernel mtx_lockflags
0.5 kernel soreceivegeneric soreceivedgram
0.5 kernel ipfastforward etherdemux

PMC: [INSTRRETIREDANY] Samples: 2936831 (100.0%) , 5410 unresolved

%SAMP IMAGE FUNCTION CALLERS
29.5 kernel mtx_lock_sleep _mtx_lock_flags:23.8 _sleep:4.2 rtalloc1fib:0.6
9.7 kernel mtx_lock_spin wakeup_one:5.9 _sleep:2.0 pmclogreserve:1.2
4.9 kernel cpusearch_lowest cpu_searchlowest
4.8 kernel cpusearch_highest cpu_search_highest:4.2 schedidletd:0.6
3.0 pmcstat _init
2.8 kernel rw_rlock ng_addresshook
1.9 kernel rw_runlock ng_addresshook
1.6 kernel inpcblookup_hash_lo in_pcblookuphash
1.4 kernel runqsteal tdqmove
1.4 kernel rnmatch rtalloc1fib
1.3 netgraph.k ngsnd_item ng_applyitem
1.2 libc.so.7 bsearch
1.0 kernel atomicfetchadd_int ng_unrefhook
0.9 kernel umazallocarg
0.9 kernel bzero
0.9 kernel ixgbexmit ixgbe_mq_startlocked
0.8 kernel spinlock_exit
0.8 kernel ethernh_input netisr_dispatchsrc
0.7 kernel ixgberxeof ixgbe_msixque
0.7 kernel umazfreearg
0.7 kernel ip_output
0.6 kernel atomicadd_barr_int ng_addresshook
0.6 kernel mtx_unlockflags
0.6 kernel critical_exit
0.6 named _init
0.6 kernel bus_dmamap_load_buf _bus_dmamap_load_mbufsg
0.5 kernel critical_enter
0.5 mpd5 _init
0.5 kernel mtx_lockflags
0.5 kernel ipfastforward etherdemux


Vladimir


--- GoldED+/W32-MSVC 1.1.5-b20130111

Valentin Davydov написал(а) к Vladimir Yesakov в Feb 15 10:25:50 по местному времени:

From: Valentin Davydov <sp@m.davydov.spb.su>

> From: Vladimir Yesakov <Vladimir.Yesakov@p202.f58.n461.z2.fidonet.org>
> Date: Fri, 27 Feb 2015 20:01:01 +0300
>
>Мы недавно объединили наши 4 сервера по 1Gbps в один с 10Gb интерфейсом. Все
>работает хорошо, но над одной загадкой я уже голову сломал. Почему systat -v и
>top -SНI показывают ~96% CPU, когда на самом деле температура не поднимается
>выше 48C ? При такой нагрузке я привык видеть ~70C.

Разная нагрузка греет CPU в разной степени. Одно дело плавающими регистрами
миллиарды раз в секунду шуровать, а совсем другое дело стоя ждать целую
микросекунду, пока соседний процессор своим контроллером вытащит из
медленной DRAM страницу, а потом ещё полмикросекунды, пока он перешлёт
её в твой кэш. При этом в обоих случаях процессор считается занятым
на 100%.

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

>FreeBSD 9.3p10, mpd5.7_1, named 9.10 больше там ничего нет. IPFW/PF/DUMMYNET
>etc. отключены. ~2500 l2tp сессий. PMC показывает вот такое.
>В сервере пара E5-2620/16GB RAM/Intel X520-SR2 (82599EB 10-Gigabit SFI/SFP+
>Network Connection)

Попробуй всю память одному процессору отдать, а второй выключить.

Вал. Дав.

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Vladimir Yesakov в Feb 15 13:38:52 по местному времени:

27 фев 2015, пятница, в 21:01 NOVT, Vladimir Yesakov написал(а):

VY> Мы недавно объединили наши 4 сервера по 1Gbps в один с 10Gb интерфейсом. Все
VY> работает хорошо, но над одной загадкой я уже голову сломал. Почему systat -v и
VY> top -SНI показывают ~96% CPU, когда на самом деле температура не поднимается
VY> выше 48C ? При такой нагрузке я привык видеть ~70C.

Хорошее охлаждение?

VY> FreeBSD 9.3p10, mpd5.7_1, named 9.10 больше там ничего нет. IPFW/PF/DUMMYNET
VY> etc. отключены. ~2500 l2tp сессий. PMC показывает вот такое.
VY> В сервере пара E5-2620/16GB RAM/Intel X520-SR2 (82599EB 10-Gigabit SFI/SFP+
VY> Network Connection)
VY> Google про "mtx_locksleep" ничего внятного не дает, кроме того, что панику в
VY> нем починили в районе 7-х версий.

Во время сна процессор не греется. И смотреть надо не top -SНI, а top -SНIP,
чтобы видеть не "среднее", а разбивку по ядрам.

Eugene
--
Choose no career
--- slrn/1.0.1 (FreeBSD)

Vladimir Yesakov написал(а) к Eugene Grosbein в Mar 15 16:52:06 по местному времени:

* Replying to a msg in CARBON.AREA (CARBON.AREA)


Нello Eugene!

28 Feb 15 13:38, you wrote to me:

VY>> FreeBSD 9.3p10, mpd5.7_1, named 9.10 больше там ничего нет.
EG> Во время сна процессор не греется. И смотреть надо не top -SНI, а top
EG> -SНIP, чтобы видеть не "среднее", а разбивку по ядрам.

Спасибо за подсказку. Картина вот такая по ядрам. Можешь подсказать как побороть ?

NIC - Intel X520-SR2, ядро - GENERIC, 9.3p10

=== Cut ===
CPU 0: 0.8% user, 0.0% nice, 18.7% system, 80.2% interrupt, 0.4% idle
CPU 1: 0.4% user, 0.0% nice, 17.9% system, 81.7% interrupt, 0.0% idle
CPU 2: 1.2% user, 0.0% nice, 15.6% system, 82.5% interrupt, 0.8% idle
CPU 3: 0.0% user, 0.0% nice, 17.5% system, 82.5% interrupt, 0.0% idle
CPU 4: 0.0% user, 0.0% nice, 16.0% system, 83.3% interrupt, 0.8% idle
CPU 5: 0.8% user, 0.0% nice, 13.2% system, 86.0% interrupt, 0.0% idle
CPU 6: 0.4% user, 0.0% nice, 16.7% system, 82.9% interrupt, 0.0% idle
CPU 7: 0.8% user, 0.0% nice, 13.6% system, 84.4% interrupt, 1.2% idle
CPU 8: 2.7% user, 0.0% nice, 90.3% system, 0.0% interrupt, 7.0% idle
CPU 9: 1.6% user, 0.0% nice, 89.9% system, 0.0% interrupt, 8.6% idle
CPU 10: 1.2% user, 0.0% nice, 92.6% system, 0.0% interrupt, 6.2% idle
CPU 11: 1.6% user, 0.0% nice, 92.6% system, 0.0% interrupt, 5.8% idle
CPU 12: 1.6% user, 0.0% nice, 94.6% system, 0.4% interrupt, 3.5% idle
CPU 13: 0.0% user, 0.0% nice, 96.5% system, 0.0% interrupt, 3.5% idle
CPU 14: 1.9% user, 0.0% nice, 92.6% system, 0.0% interrupt, 5.4% idle
CPU 15: 0.4% user, 0.0% nice, 94.6% system, 0.0% interrupt, 5.1% idle
CPU 16: 0.8% user, 0.0% nice, 93.4% system, 0.0% interrupt, 5.8% idle
CPU 17: 1.9% user, 0.0% nice, 94.9% system, 0.0% interrupt, 3.1% idle
CPU 18: 1.2% user, 0.0% nice, 95.3% system, 0.0% interrupt, 3.5% idle
CPU 19: 0.4% user, 0.0% nice, 95.7% system, 0.4% interrupt, 3.5% idle
CPU 20: 1.2% user, 0.0% nice, 94.6% system, 0.4% interrupt, 3.9% idle
CPU 21: 0.8% user, 0.0% nice, 96.9% system, 0.0% interrupt, 2.3% idle
CPU 22: 1.2% user, 0.0% nice, 93.4% system, 0.0% interrupt, 5.4% idle
CPU 23: 1.6% user, 0.0% nice, 94.9% system, 0.0% interrupt, 3.5% idle
=== Cut ===

Vladimir


--- GoldED+/W32-MSVC 1.1.5-b20130111

Eugene Grosbein написал(а) к Vladimir Yesakov в Mar 15 16:37:33 по местному времени:

01 мар 2015, воскресенье, в 17:52 NOVT, Vladimir Yesakov написал(а):

VY>>> FreeBSD 9.3p10, mpd5.7_1, named 9.10 больше там ничего нет.
EG>> Во время сна процессор не греется. И смотреть надо не top -SНI, а top
EG>> -SНIP, чтобы видеть не "среднее", а разбивку по ядрам.
VY> Спасибо за подсказку. Картина вот такая по ядрам. Можешь подсказать как
VY> побороть ?
VY> NIC - Intel X520-SR2, ядро - GENERIC, 9.3p10
VY> === Cut ===
VY> CPU 0: 0.8% user, 0.0% nice, 18.7% system, 80.2% interrupt, 0.4% idle
VY> CPU 1: 0.4% user, 0.0% nice, 17.9% system, 81.7% interrupt, 0.0% idle
VY> CPU 2: 1.2% user, 0.0% nice, 15.6% system, 82.5% interrupt, 0.8% idle
VY> CPU 3: 0.0% user, 0.0% nice, 17.5% system, 82.5% interrupt, 0.0% idle
VY> CPU 4: 0.0% user, 0.0% nice, 16.0% system, 83.3% interrupt, 0.8% idle
VY> CPU 5: 0.8% user, 0.0% nice, 13.2% system, 86.0% interrupt, 0.0% idle
VY> CPU 6: 0.4% user, 0.0% nice, 16.7% system, 82.9% interrupt, 0.0% idle
VY> CPU 7: 0.8% user, 0.0% nice, 13.6% system, 84.4% interrupt, 1.2% idle
VY> CPU 8: 2.7% user, 0.0% nice, 90.3% system, 0.0% interrupt, 7.0% idle

По умолчанию драйвер настраивает сетевую использовать не более 8 очередей,
но можно увеличить до 16-ти через loader.conf:

hw.ixgbe.num_queues=16

Если надо больше - ставь две карты, объединяй их в lagg и пусть коммутатор
распараллеливает трафик по двум сетевым, так можно получить до 32 очередей.

Одна очередь загружает одно ядро CPU.

Eugene
--- slrn/1.0.1 (FreeBSD)

Vladimir Yesakov написал(а) к Eugene Grosbein в Mar 15 20:40:36 по местному времени:

* Replying to a msg in CARBON.AREA (CARBON.AREA)


Нello Eugene!

02 Mar 15 16:37, you wrote to me:

VY>>>> FreeBSD 9.3p10, mpd5.7_1, named 9.10 больше там ничего нет.
EG>>> Во время сна процессор не греется. И смотреть надо не top -SНI,
EG>>> а top -SНIP, чтобы видеть не "среднее", а разбивку по ядрам.
VY>> Спасибо за подсказку. Картина вот такая по ядрам. Можешь
VY>> подсказать как побороть ? NIC - Intel X520-SR2, ядро - GENERIC,
VY>> 9.3p10
EG> По умолчанию драйвер настраивает сетевую использовать не более 8
EG> очередей, но можно увеличить до 16-ти через loader.conf:
EG> hw.ixgbe.num_queues=16

Тут и была моя ошибка. Я написал hw.ix.num_queues=12, а не ixgbe.

EG> Если надо больше - ставь две карты, объединяй их в lagg и пусть
EG> коммутатор распараллеливает трафик по двум сетевым, так можно получить
EG> до 32 очередей.

По спецификации эта карточка может 128 очередей, вроде... (линк разошелся на 2 строки)
http://www.intel.com/content/www/us/...t-controllers/
82599-10-gbe-controller-datasheet.html

EG> Одна очередь загружает одно ядро CPU.

Еще раз спасибо.

3 момента не совсем ясны:

1) стоит ли включить НT и сделать 24 очереди ? можно ли 2 порта карточки по 6(12) очередей прибить каждый к своему CPU ?
2) lro - стоит включить/выключить ? интернет очень противоречив на эту тему.
3) net.isr.dispatch, net.isr.numthreads и net.isr.bindthreads - как лучше ? Сейчас поставил direct,12 и 1 (без НT)

В идеале хотелось бы получить полные 10G с сервера... ( карточка на 2 порта, в один принимаем l2tp, а в другом Internet )

Vladimir


--- GoldED+/W32-MSVC 1.1.5-b20130111

Eugene Grosbein написал(а) к Vladimir Yesakov в Mar 15 15:05:50 по местному времени:

02 мар 2015, понедельник, в 21:40 NOVT, Vladimir Yesakov написал(а):

VY> По спецификации эта карточка может 128 очередей, вроде... (линк разошелся на 2
VY> строки)
VY> http://www.intel.com/content/www/us/...t-controllers/
VY> 82599-10-gbe-controller-datasheet.html

Тут важны очереди на прием.

EG>> Одна очередь загружает одно ядро CPU.
VY> Еще раз спасибо.
VY> 3 момента не совсем ясны:
VY> 1) стоит ли включить НT и сделать 24 очереди ?

IMНO не стоит, потому как НT-ядра всё-таки не полноценные и как потом
мониторить/интерпретировать загруженность сервера - непонятно.
С честными ядрами всё однозначно.

VY> можно ли 2 порта карточки по
VY> 6(12) очередей прибить каждый к своему CPU ?

Можно; и драйвер, afaik, делает это по умолчанию.

VY> 2) lro - стоит включить/выключить ? интернет очень противоречив на эту тему.

Эта опция не для роутеров, а для контент-серверов, для TCP.
Роутер почти весь трафик обрабатывает уровнем ниже.

VY> 3) net.isr.dispatch, net.isr.numthreads и net.isr.bindthreads - как лучше ?
VY> Сейчас поставил direct,12 и 1 (без НT)

Так и оставь.

VY> В идеале хотелось бы получить полные 10G с сервера... ( карточка на 2 порта, в
VY> один принимаем l2tp, а в другом Internet )

Это может быть нетривиально, но пробуй.

Eugene
--- slrn/1.0.1 (FreeBSD)

Vladimir Yesakov написал(а) к Eugene Grosbein в Mar 15 20:28:48 по местному времени:

* Replying to a msg in CARBON.AREA (CARBON.AREA)


Нello Eugene!

Я заранее прошу прощения, длинновато получилось...

03 Mar 15 15:05, you wrote to me:

VY>> По спецификации эта карточка может 128 очередей, вроде... (линк
VY>> разошелся на 2 строки)
VY>> http://www.intel.com/content/www/us/...t-controllers/
VY>> 82599-10-gbe-controller-datasheet.html
EG> Тут важны очереди на прием.

ну, 12 очередей на порт включилось...

VY>> можно ли 2 порта карточки по 6(12) очередей прибить каждый к своему
VY>> CPU ?
EG> Можно; и драйвер, afaik, делает это по умолчанию.

Оказалось, что нет. Сделал 6 очередей, получил нагрузку на первые шесть ядер. Обе карты прицепились к CPU 0-5. Разобрался как прибить руками через setcpu, прибил ix0 к CPU 0-5 и ix1 к 6-11. Получилось вроде красиво.

VY>> 2) lro - стоит включить/выключить ? интернет очень противоречив на
VY>> эту тему.
EG> Эта опция не для роутеров, а для контент-серверов, для TCP.
EG> Роутер почти весь трафик обрабатывает уровнем ниже.

Уровнем ниже чего? TCP ? Это да. Или "large" там подразумевает несколько пакетов относящихся к одному TCP соединению сразу в socket? Я не нашел такой информации.
Однако принять-то пакет все равно надо. И я прочитал, что с этой опцией карта сама кладет принятый пакет в буфер, без использования CPU.
И еще на этом сервере L2TP (mpd5) терминация. Короче с этим непонятно... Сколько людей - столько мнений...

VY>> 3) net.isr.dispatch, net.isr.numthreads и net.isr.bindthreads -
VY>> как лучше ? Сейчас поставил direct,12 и 1 (без НT)
EG> Так и оставь.
VY>> В идеале хотелось бы получить полные 10G с сервера... ( карточка
VY>> на 2 порта, в один принимаем l2tp, а в другом Internet )
EG> Это может быть нетривиально, но пробуй.

PPS взяты с "netstat -i 1"

Пока вижу следующее: CPU 81%, 2700 tunnels, 3.7Gbps, 1.3M pps IN, 1.4M pps OUT, ядра загружены более-менее равномерно, потерь нет.

> НO !!!

CPU загружен 40% system, 40% interrupt и pmcstat показывает такую вот фигню:

PMC: [INSTRRETIREDANY] Samples: 123604 (100.0%) , 1069 unresolved

%SAMP IMAGE FUNCTION CALLERS
11.9 kernel schedidletd forkexit
5.1 kernel rw_rlock rtalloc1_fib:1.8 ng_addresshook:1.7
5.1 kernel mtx_lock_sleep _mtx_lockflags
4.3 kernel mtx_lock_spin wakeup_one:1.9 turnstile_trywait:0.9 pmclog_reserve:0.8 sleep:0.6
4.1 kernel selectcheck_badfd kernselect
2.4 kernel rw_runlock ng_addresshook:0.9 arpresolve:0.5
2.3 kernel rnmatch rtalloc1fib
2.3 kernel cpusearch_lowest cpu_search_lowest:1.4 schedpickcpu:0.9
2.1 pmcstat _init
2.0 kernel inpcblookup_hash_lo in_pcblookuphash

> Соседний сервер, где один физический CPU, такая же карточка и нету L2TP,
> но есть немножко PF правил.

CPU 1% system, 27% interrupt, 3Gbps, 0.5M pps IN, 0.5M pps OUT, ядра загружены более-менее равномерно, потерь нет.

PMC: [INSTRRETIREDANY] Samples: 85109 (100.0%) , 4803 unresolved

%SAMP IMAGE FUNCTION CALLERS
7.0 kernel bcmp ngapplyitem
6.4 pf.ko pftest_rule pftest
6.2 kernel cpusearch_highest cpu_search_highest:5.0 schedidletd:1.1
3.6 pf.ko pftest pf_check_in:2.0 pf_checkout:1.7
2.9 kernel bzero pftest:0.6 ng_packagedata:0.5
2.6 kernel _rw_rlock pf_test:0.8 in_lltablelookup:0.6
2.5 kernel _mtx_unlock_flags ng_address_hook:0.8 pf_find_state:0.6 ixgberxeof:0.5
2.4 libc.so.7 bsearch
2.4 kernel rw_runlock_cookie pf_test:0.8 arpresolve:0.8 inlocalip:0.5
2.4 kernel jenkinshash32 pf_findstate
2.2 kernel cpusearch_lowest cpu_searchlowest
2.1 kernel umazalloc_arg ng_package_data:1.0 mdup:0.6
2.1 kernel _mtx_lock_flags ng_address_hook:1.0 pf_findstate:0.6
2.0 kernel ipfastforward etherdemux

Я не могу понять 2 вещи: трафика примерно одинаково, а PPS в три раза отличается; CPU system - на одном ~0%, на другом половина от общей загрузки, да еще и в "sched_idletd" - в ожидании грубо говоря. Я уже подумываю, а не выдернуть ли один CPU и посмотреть что будет?

Vladimir


--- GoldED+/W32-MSVC 1.1.5-b20130111

Eugene Grosbein написал(а) к Vladimir Yesakov в Mar 15 13:57:53 по местному времени:

03 мар 2015, вторник, в 21:28 NOVT, Vladimir Yesakov написал(а):

VY>>> 2) lro - стоит включить/выключить ? интернет очень противоречив на
VY>>> эту тему.
EG>> Эта опция не для роутеров, а для контент-серверов, для TCP.
EG>> Роутер почти весь трафик обрабатывает уровнем ниже.
VY> Уровнем ниже чего? TCP ? Это да. Или "large" там подразумевает несколько
VY> пакетов относящихся к одному TCP соединению сразу в socket? Я не нашел такой
VY> информации.
VY> Однако принять-то пакет все равно надо. И я прочитал, что с этой опцией
VY> карта сама кладет принятый пакет в буфер, без использования CPU.

У тебя разве много TCP-трафика идёт в сокеты для самого сервера?

VY> И еще на этом сервере L2TP (mpd5) терминация. Короче с этим непонятно...
VY> Сколько людей - столько мнений...

L2TP-трафик это UDP, не TCP.

VY> Я не могу понять 2 вещи: трафика примерно одинаково, а PPS в три раза
VY> отличается;

Позахватывай tcpdump-ом немножко трафика и поизучай полученный pcap-файл
на тему реальной длины пакетов. Может у тебя на самом деле куча мелких
пакетов на одном из серверов (вирусы какие, флуд).

VY> CPU system - на одном ~0%, на другом половина от общей загрузки

Понаблюдай top -m io -o total

Eugene
--
Научить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Научить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.
--- slrn/1.0.1 (FreeBSD)

Vladimir Yesakov написал(а) к Eugene Grosbein в Mar 15 19:31:48 по местному времени:


Нello Eugene!

04 Mar 15 13:57, you wrote to me:

EG> 03 мар 2015, вторник, в 21:28 NOVT, Vladimir Yesakov написал(а):
VY>>>> 2) lro - стоит включить/выключить ? интернет очень противоречив
VY>>>> на эту тему.
EG>>> Эта опция не для роутеров, а для контент-серверов, для TCP.
EG>>> Роутер почти весь трафик обрабатывает уровнем ниже.
VY>> Короче с этим непонятно... Сколько людей - столько мнений...

Похоже разница в пределах погрешности измерения... Источник:
http://bsdrp.net/documentation/techn...cs/performance
Искать "Disabling LRO and TSO"

Vladimir


--- GoldED+/W32-MSVC 1.1.5-b20130111