1
|
Linux секция за напреднали / Начини за увеличаване на бързодействието / Brctl на многопроцесорна система
|
-: Dec 11, 2007, 12:36
|
Цитат (gat3way @ Дек. 11 2007,00:13) | Това има много просто обяснение. Просто губиш предимствата на кеша. |
Mxm Така си го пишеше и в гугъла. Затова даже е препоръчително да се ползва едно ядро за двете неща. Всъщност, експериментирах и така :етх0 и етх1 в едно ядро. Но нещо не ми хареса. Сега тепърва ще продължа с експериментите. Както ще поработя и върху някой финни настройки на самите мрежови карти относно буферирания, брой прекъсвания и максимум време за задържане на прекъсванията.
Ще пиша допълнително за резултатите.
Между другото, това с НАПИ нещо немога да намеря добра информация в нета. Явно не търся правилно. Но пише, че ако драйвера поддържа НАПИ (което е така за е1000), то се ползва по подразбиране. Имате ли наблюдения за това ?
|
|
|
2
|
Linux секция за напреднали / Начини за увеличаване на бързодействието / Brctl на многопроцесорна система
|
-: Dec 10, 2007, 22:47
|
Цитат (zeridon @ Дек. 10 2007,21:56) | Сподели с бедните нещастници '> как си го направил и какво е точно подобрението.
Аз лично ще се радвам на: * някакви статистики от преди това (PPS, Mbit/s, IRQ/s) * някакви статистики след това (--//--)
Също и малко лични наблюдения от към responsiveness на машината не вярвам някой да откаже.
Друго което ми идва в момента на акъла е ... какво ти е HZ-то на машината (т.е. jiffies колко имаш :П) Постигал съм учудващо добри резултати със HZ=250 s 1000 вече почва да се поебава малко. |
Здрасти, не съм много навътре със такъв фин контрол на линукс. Но пък от друга страна ми доста интересно да го разчовъркам това.
Та по въпроса, не съм замервал като цяло перформънса на машината.
Засега успях да поекспериментирам с прекъсванията. Интересното е, че ksoftirqd се вдига значително повече върху процесорите на които е разпределена мрежовата карта (отколкото когато е върху 1 процеосор). Или като цяло, може така да ми се струва, тъй като ТОП повечко ksoftirqd отгоре. Ще имам по-точно данни, като поработи машината малко повечко и мога да видя колко от CPU time е разпределен върху ksoftirqd.
Другото което е интересно, че пинговете през машината паднаха с около 20-30% при разпределяне на прекъсванията върху повече от един процесор.
Това което не трябва да се прави е да се рапределят прекъсванията между процесори които не са в едно ядро. Пинговете през машината се вдигат значително.
Машината е следната:
Примерен код | processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Xeon(TM) CPU 2.66GHz stepping : 4 cpu MHz : 2656.000 cache size : 2048 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips : 5323.96 clflush size : 64
processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Xeon(TM) CPU 2.66GHz stepping : 4 cpu MHz : 2656.000 cache size : 2048 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips : 5320.02 clflush size : 64
processor : 2 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Xeon(TM) CPU 2.66GHz stepping : 4 cpu MHz : 2656.000 cache size : 2048 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips : 5320.07 clflush size : 64
processor : 3 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Xeon(TM) CPU 2.66GHz stepping : 4 cpu MHz : 2656.000 cache size : 2048 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips : 5320.09 clflush size : 64
processor : 4 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Xeon(TM) CPU 2.66GHz stepping : 4 cpu MHz : 2656.000 cache size : 2048 KB physical id : 1 siblings : 4 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips : 5320.12 clflush size : 64
processor : 5 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Xeon(TM) CPU 2.66GHz stepping : 4 cpu MHz : 2656.000 cache size : 2048 KB physical id : 1 siblings : 4 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips : 5320.12 clflush size : 64
processor : 6 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Xeon(TM) CPU 2.66GHz stepping : 4 cpu MHz : 2656.000 cache size : 2048 KB physical id : 1 siblings : 4 core id : 1 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips : 5320.13 clflush size : 64
processor : 7 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Xeon(TM) CPU 2.66GHz stepping : 4 cpu MHz : 2656.000 cache size : 2048 KB physical id : 1 siblings : 4 core id : 1 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips : 5320.11 clflush size : 64
|
Тоест идеята е да не разпределяш eth0 на процесор 1 и 3 или 1 и 7 (тогава положението е лошо)
|
|
|
4
|
Linux секция за напреднали / Начини за увеличаване на бързодействието / Brctl на многопроцесорна система
|
-: Dec 06, 2007, 19:37
|
tarator, точно ей това тук много не ми е ясно. Според това до колко разбирам, като почне да се шепва трафика, процесора асоцииран с мрежовата карта почва да не смогва и при усилен трафик и ksoftirqd почва да "обира" новопристигналите пакети (тук може и да греша). Когато направиш бридж и върху него приложиш шейпване, то тогава самотошейпване ще бъде ли разпределено върху всичките процесори занимаващи се с прекъсванията от мрежовите карти в този бридж? Или просто пак ще се изпълнява от 1 процесор ?
gat3way, под появяване имах в предвид, че започва да отнема сериозно време на процесора. Иначе при нормална работа, ksoftirqd/x си седи като процес. Благодаря ти за препоръката. Не съм се занимавал с това NAPI и нямам изобщо представа за какво става въпрос и дали дриверите (които са си от дистрибуцията на федора) поддържат NAPI.
Zeridon, Ще разчета подробно сайта и нета относно NAPI и ще видя какво може да ми е в помощ.
Благодаря Ви още веднъж за отговорите.
|
|
|
5
|
Linux секция за напреднали / Начини за увеличаване на бързодействието / Brctl на многопроцесорна система
|
-: Dec 06, 2007, 01:02
|
Ситуацията е следната: Процесори: 2хDual core Xeon със HT NIC: 4хIntel Gigabit. Всички прекъсвания генерирани от дадена мрежова карта се обработват от 1 определен процесор (освен ако irqbalance не промени процесора). Ако върху мрежовата карта се приложат някакви дисциплини за контролиране на трафика, то този процесор се натоварва в зависимост от PPS и големината на трафика и съответно се "появява" ksoftirqd/x.
Мисля си да обединя 3 от мрежовите карти в bridge чрез brctl и върху brиdge-а приложа въпросните дисциплини за контролиране на трафика. Изрових гугъла и неможах да намеря информация относно: Ще остане ли обработката на прекъсванията от тези карти върху различни процесори или просто новият bridge ще се използва един единствен процесор ? Някой правил ли е подобни проби и има ли наблюдения върху подобни разпределения на прекъсванията ?
|
|
|
|