Dotaz: Rozlozeni spicich procesu na jadrech

[MP]

Moje google fu tady nejak selhava. Jestli nekdo tusi, proc a jak nebo hodi dobry odkaz, budu rad.

Mam x jadrovy stroj (x>10). Bezi na ni db a apache. Mam nyni rucne nastaveno:

1] cpu0 - irq disk

2] cpu1 - irq eth0

3] cpu2 - irq eth1

A ted jde o tohle. Kdyz si vypisu seznam procesu, tak treba u db mam 100+ procesu. Polovina z nich "spi" na stejnem jadru (v tomhle pripade 2). Podobne apache (3). Proc? Pokud pocitam s tim, ze ten proces predtim bezel na nejakem jadre a ted spi, proc jako posledni cpu, na kterem bezel, neni vice nahodny?

Odpovědi

[rastos]

Mam x jadrovy stroj (x>10). Bezi na ni db a apache. Mam nyni rucne nastaveno: ...

Nastavené to máš čím?

[MP]

Pomoci echo do /proc/irq/id/smp_affinity. Mel jsem blkid/eth* vse na prvnim jadru, zadny irqbalancing...ale mozna dam jeste sanci irqbalance, ale ne na kazdem stroji funguje :/ (sdileni cache)

[Michal]

Kernel sdružuje procesy tak, aby co nejvíc jader mohlo chrápat kvůli úspoře energie. Migrace spícího procesu (cache vyflushovaná nebo pro budoucí request pravděpodobně irelevantní) má zanedbatelnou režii.

Ve zkratce: neřeš kraviny a nech kernel ať si dělá svoje. Energie vynaložená na cokoliv jiného (vyladění parametrů DB, FS...) bude mít násobně větší přínos. Už to přiřazení IRQ pro konkrétní jádra je pravděpodobně chybou.

[Michal Kubeček]

Už to přiřazení IRQ pro konkrétní jádra je pravděpodobně chybou.

Moc bych se nedivil, kdyby to ve skutečnosti byla příčina "problému" (jestli je to skutečný problém (resp. jeho příznak), to je otázka).

[MP]

No, co jsme kolem toho zkoumali, tak zrovna i ten dotycny stroj (jak host, tak guest) mel vsechna blkid/eth* preruseni na prvnim jadre...proto jsme to zkusili rozhodit.