Load average 8 на машыне з 4 ядрамі, значыць машыне патрэбныя ядры. Гэтую фразу я вымаўляў на планёрцы. Ніхто не запярэчыў. Чаго я ніколі не рабіў, дык гэта не падымаў гэты лік знарок больш чым адным спосабам. Падняў, на ціхім серверы з 4 ядрамі, дзе больш нічога не круціцца.
Першы прагон заганяе 4 працэсы ў чысты арыфметычны цыкл, а гэта самае блізкае да азначэння нагрузкі на працэсар, што я магу сабраць. Другі прагон запускае 8 працэсаў, якія пішуць на дыск. Абодва падымаюць load average вышэй за 8. Пра працэсар з іх толькі адзін.
Лік адстае мацней, чым прынята думаць
Перад цікавай часткай нудная, якая нуднай не аказалася. Чатыры цыклы стартуюць пры load 0.18. Працэсар стаіць на 100 адсотках з першай жа секунды, то бок машына занятая цалкам і адразу.
Пасля цэлай хвіліны чатырох насычаных ядраў хвіліннае сярэдняе паказвае 2.67. Не 4. Гэта зацухаючае сярэдняе з пастаяннай у 60 секунд, таму праз хвіліну ты бачыш прыкладна 63 адсоткі таго, што адбываецца. Рэшта даходзіць толькі праз 3 ці 4 хвіліны.
Падчас аварыі гэта рэжа ў абодва бакі. Машына, якая толькі што пайшла пад ваду, выглядае на дзве трэці настолькі кепска, наколькі ёй кепска. Машына, якую толькі што выратавалі, выглядае кепска яшчэ 3 хвіліны.
Тая ж васьмёрка, сабраная з іншага
Далей дыск. 8 працэсаў пішуць па 300 мегабайт у цыкле, мінаючы старонкавы кэш, каб запісы сапраўды сыходзілі на прыладу.
Load 8.10, пры гэтым працэсар робіць сапраўдную працу 36.5 адсотка часу. Чакае дыск ён 63.3 адсотка. 7 з 8 пісьменнікаў у любы момант сядзяць у непарыўным сне, і гэта той стан, які Linux лічыць нароўні з гатовымі да ліку. Менавіта гэтае рашэнне і робіць лік непрацэсарным.
Пара і ёсць сэнс замеру. 8.19 і 8.10 гэта адна і тая ж трывога на дашбордзе. Адна лечыцца ядрамі. Другая лечыцца хуткім дыскам або тым, каб пісаць менш, а ядры пры ёй прастойваюць на дзве трэці.
Дзе я спатыкнуўся
Першая спроба зрабіць дыскавую палову дыск не мерала ўвогуле. Я прымусіў 8 пісьменнікаў клікаць fdatasync, але дазволіў старонкаваму кэшу забраць запісы. Прагон вярнуў load 8.19 пры працэсары на 99 адсоткаў і без ніводнага заблакаванага працэсу, то бок левую рамку з той карцінкі. Я напісаў замер капіравання памяці і назваў яго ціскам на дыск.
Лечыцца гэта абыходам кэша, каб запісы даходзілі да прылады. Сумленная версія ліку злева гучыць так: ён сапраўдны, ён роўны 8.19, і пра дыск ён не кажа нічога.
Чаго я не правяраў
Ці дастаткова часта ядро пералічвае гэты лік, каб верыць яму на кроку ў 5 секунд: лічыць яно па таймеры, а не на кожную змену, так што мае замеры цалкам маглі чытаць яго акругленне. Ці лічыцца гэтак жа непарыўны сон на сеткавым сховішчы, а гэта якраз той выпадак, які важны ў дата-цэнтры. І як усё гэта выглядае ўнутры кантэйнера, дзе load average належыць хасту, а ліміты жывуць у cgroup. Чакаю, што там свая разнавіднасць хлусні.
Вузкае сцвярджэнне пра тую самую фразу, якую я казаў. Load 8 на 4 ядрах не азначае, што ўперліся ў працэсар. Перш чым казаць пра ядры, трэба паглядзець, чым занятыя працэсы: тая ж васьмёрка бывае чатырма ядрамі арыфметыкі, а бывае сямю працэсамі, якія чакаюць прыладу, што ад куплі машыны большай хутчэйшай не стане.