24-ядрен процесор, а не мога да помръдна курсора на мишката

39
5480
24-ядрен процесор

Превод на 24-core CPU and I can’t move my mouse

Всичко започна, когато моят компютър започна да се забавя. А това е моят работен компютър с Windows 10 и 24-ядрен (48 потока) процесор, натоварен до около 50%. Бързият SSD почти не се използваше. И все пак, когато помръднах мишката, курсорът не реагира веднага. Имах случаи на лагване с продължителност няколко секунди.

И този път направих това, което правя във всички подобни случаи – записах и трасирах събитията с помощта на ETW (Event Tracing for Windows). И да, открих бъг в ОС Windows 10, сериозно влияещ на производителността при завършването на процесите.

Трасирането с помощта на ETW показа, че потребителският интерфейс (UI) се срива в редица програми. Започнах с изследването на 1,125-секундното закъснение на курсора в диспечера на задачите Task Manager:

По-долният скрийншот показва използването на процесора от операционната система по време на този лаг. Процесите се виждат, но и добре се забелязва, че процесорът почти не се натоварва над 50%.

Таблицата CPU Usage (Precise) показва, че UI потокът на диспечера на задачите постоянно се блокира от извикванията на функцията SendMessageW, която явно изчаква в критична зона на ядрото, дълбоко в стека на извикванията win32kbase.sys!EnterCrit (тук това не е показано).

Ръчно преминах по цялата верига на изчакванията и отметнах десетки процеси, за да намеря, кой изяжда ресурсите на потребителския интерфейс. Получи се следното:

Taskmgr.exe (72392) увисва на 1,125 секунда (MsgCheckDelay) на нишката 69,196. Най-голямо забавяне от 115,6 ms внася win32kbase.sys!EnterCrit, подготвен за изпълнение от процеса conhost.exe (16264) на нишка 2560 в точка 3.273101862. След това conhost.exe (16264), 2560 е подготвен за 3.273077782 след изчакване на 115 640,966 ms от процеса mstsc.exe (79392), 71272. От своя страна mstsc.exe е подготвен (същото време на забавяне) от процеса UIforETW.exe (78120), 79584, който пък е подготвен от процеса conhost.exe (16264), 58696, който от своя страна е подготвен от процеса gomacc.exe (93668), 59948, подготвен от процеса gomacc.exe (95164), 76844.

Отказах се да продължавам, понеже повечето процеси преустановяват блокажа само след няколко микросекунди. Но в крайна сметка открих няколко процеса (процесите gomacc.exe) които задържат блокировката няколко стотици микросекунди. Или може да се каже, че те са подготвени от някой, който задържа блокировката, а след няколко микросекунди те подготвят друг процес за нейното прекъсване. Всички тези процеси свалят блокировката в рамките на NtGdiCloseProcess.

Омръзна ми ръчно да проследявам всички тези процеси на изчаквания и реших да прегледам, доколко често се среща този стек с извиквания. Това стана, като преместих колонката Ready Thread Stack наляво и потърсих в нея NtGdiCloseProcess. След това използвах опцията View Callers -> By Function във WPA, за да видя всички стекове Ready Thread Stacks с тази функция. Родителските стекове са показани по-долу:

Програмата изброи 5768 контекстни превключвания, докато процесът NtGdiCloseProcess се намира в стека Ready Thread Stack, като всяко едно от тях обозначава момента, когато се освобождава критична секция. Взети заедно, потоците в тези стекове, съхраняващи извикванията, изчакват общо 63,3 секунди – доста впечатляващо в сравнение с наблюдавания от мен лаг от 1,125 секунди. Ако всяко от тези събития протича след като потока задържа блокирането само с 200 микросекунди, получава се именно забавянето на интерфейса с 1,125 секунди.

Тази част на Windows не ми е особено позната, но съчетанието PspExitThread и NtGdiCloseProcess ясно показва, че това поведение се проявява при завършването на процеса.

Всичко това се случи по време на компилирането на Chrome, а това поражда наистина много процеси. А и аз използвах нашата фирмена разпределена система за компилиране, която създава много процеси, но и ги завършва много бързо.

Следващата стъпка бе да пресметна, колко точно време е изминало и изгубено вътре в NtGdiCloseProcess. Пренесох таблицата CPU Usage (Sampled) във WPA, за да разгледам извикванията на NtGdiCloseProcess. В скрийншота по-долу се вижда, че от 1,125 секундния лаг. около 1085 милисекунди са изразходвани от процеса NtGdiCloseProcess, а това са 96% от цялото време:

А това е твърде лошо – как може 96% от времето да бъде изразходвано от една функция и да не остане време за показване на съобщения и за да се обнови местоположението на курсора. Задълбочих се в този проблем и реших да направя експеримент. Написах тестова програма, която с максимална скорост създава 1000 процеса, изчаква 0,5 секунди и след това подава команда за едновременното завършване на всички тези процеси. В по-долния скрийншот е показано действието на тази програма на моя домашен лаптоп с 4-ядрен (8 потока) процесор:

Да разгледаме тази диаграма. Създаването на процеси е ограничено от възможностите на процесора и това е в реда на нещата. Но спирането на процесите се ограничава от процесора само в началото и края (червените пикове в дясната част, показваща спирането на процесите). Съвсем ясно се вижда, че в средата има един голям промеждутък (около една секунда), където алгоритъмът се обработва последователно и се използва само един от осемте достъпни потока в системата. Да си припомним, че моята програма създаде 1000 процеса и всички те се борят за единствената блокировка, намираща се в NtGdiCloseProcess. Това е сериозен проблем. Именно този промеждутък показва времето на лага, когато програмите силно се забавят, а движенията на курсора почти спират. Понякога това забавяне се разтяга до няколко секунди.

Забелязах че проблемът се задълбочава, когато компютърът е работил известно време. Разбира се, рестартирах компютъра и отново пуснах своята тестова програма. Спирането на процесите не бе толкова тежко, но проблемът си остана дори и в току що стартираната машина.

И тук се сетих за нещо друго. Стартирах своята програма на старичък компютър от 2008 година с Windows 7 и Intel Core 2 Q8200. Резултатите са съвсем съвсем други:

Създаването на нови процеси става по-бавно, както може да се очаква от един много по-слаб процесор. Но тяхното спиране и завършване става дори малко по-бързо от моя нов лаптоп със солиден процесор. Но по-важното е, че всичко става изцяло паралелно и няма престояване на потоци. Това се вижда в дясната страна на изображението, показващо спирането на процесите – промеждутък напълно липсва.

Това показва, че липсата на паралелно приключване на процесите е нов проблем, появил се някъде между Windows 7 и Windows 10.

48 потока, а 47 от тях бездействат

Законът на Амдал гласи, че ако разпределите своя алгоритъм да се изпълнява на няколко процесорни ядра, то сумарното време на неговото изпълнение зависи от времето на изпълнение на най-дългия фрагмент, който не може да се разпаралели. Когато активно използвам своя работен компютър в продължение на няколко дни, проблемът се изявява все по-явно, а големият брой ядра с нищо не помага. За да ускоря компилацията и през това време курсорът да се движи и интерфейсът да реагира, трябва да рестартирам машината всеки ден. Но при проявата на този неприятен бъг, натоварването на процесора почти не преминава 50%, а дискът не се използва. Връщането към Windows 7 започна да ми изглежда все по-привлекателно.

Всъщност, добавянето на процесорни ядра в моята компютърна система забавя скоростта на реакция на потребителския интерфейс. Просто компилирането на Chrome поражда много процеси, а ако имате повече ядра, толкова повече процеси ще се борят за приключването на работата си. Тоест, май вместо да казвам „24-ядрен процесор, а не мога да помръдна курсора на мишката“ е по-добре да кажа „24-ядрен процесор и затова не мога да мръдна курсора на мишката„.

Съобщихме за този проблем на Microsoft и сега програмистите оглеждат нещата

И още нещо…

Ето как изглежда моята тестова програма на моя мощен 24-ядрен компютър:

Виждате ли малката червена линия в долния десен ъгъл? Това е нагледна демонстрация на закона на Амдал, когато 98% от ресурсите на машината престояват почти две секунди, понеже процедурата по завършване на процесите използва само един поток и не може да ги спре. А аз не мога да помръдна курсора на мишката.

39
ДОБАВИ КОМЕНТАР

avatar
14 Коментари
25 Отговори на коментарите
26 Последователи
 
Коментарът с най-много реакции
Най-горещият коментар
28 Автори на коментарите
ColombinoПитър ПанЛим Ах Ланеб НбиOngo BongoКиро Кирпича Автори на последните коментари
  Абонирай се  
нови стари оценка
Извести ме за
Кольо
Кольо

Скалирането с Уиндоус на повече от 8 ядра, не е нов проблем.

copy/translate/paste
copy/translate/paste

Какво точно искате да покажете или демонстрирате с почти дословно првписана/преведена статия?
на колко от потребителите на сайта би била полезна много специфично описаният проблем?
Сайта за пълнеж ли вече се ползва или имате определен таргет статии да списвате?
Не омаловажавам други списани от Вас статии, много от които полезни, но тук вече прекалихте или аудиторията е станала прекалено некомпетентна?!
Защо и кому наистина би била пак повтарям толкова специфичен и частен случай?!

Oceanic815
Oceanic815

Не е частен случай. На моята дву-процесорна щайга с по 12 ядра Ексела върши същите глупости. Натоварва не повече от 17% процесора/те и чакаш да се генерира доклада 40 минути вместо час и половина. Даже установих, че ако изключа Hyper-Threading-a нещата дори се подобряват.

Colombino
Colombino

Полезно е да се знае това. Освен това има линк към оригиналната статия и човек ако му е сложно да се сеща кое са кръстили поток, кое блокаж, може да си я прочете на простоанглийски. А и тоя ETW не го знаех, може да се окаже полезен. Подозирам, че доста програмисти четат тук. Аз лично не съм се сблъскал с проблема, защото десктопа си го ползвам само за терминал и билдвам на Win 7, но ако започне да ми лагва, ще се сетя поне от какво може да е. Билдването на C++ се прави с нов процес за всеки cpp… Виж още »

Киро Кирпича
Киро Кирпича

Може да си „билдваш“ на воля и под линукс нали? И под Мак Ос.. А колко ефективно ползва твоя компилатор наличният хардуер? Студиото с което програмираш разпознава ли добре 4-6-8-12 ядрени процесори или ги третира като двуядрени и налива всичко на опашката.. Тоя рапон писал статията така и не каза тая програма дето я драснал дали при инсталирано копие на същата 10-ка под стария хардуер прави същите мизерии. Не каза дали това е преди или след кретенията с кръпките по тематика Spectre / Meltdown.. или не.. Има ли същите проблеми под Линукс на същия хардуер или не.. Тоест, ако проблема… Виж още »

Colombino
Colombino

Пиша софтуер, който се компилира за Уиндоус, Линукс, 32 и 64 бита. Студиото ползва колкото процесора му дадеш, но не винаги билдвам със самото студио. Има инструменти за разпределено билдване по мрежата – Incredibuild, FastBuild, а сигурно има и други, които аз не познавам, но биха се възползвали от повече ядра. Не разбрах какво точно ти пука на каква операционна система си билдвам – процесорите са си процесори. Говорим за бъг, който вече е фикснат в Win 10, а специално билдването е просто пример към тоя, дето не вярва в ползата от многоядрените процесори.

Същия
Същия

Абе, бастун. Да не мислиш че този сайт трябва да пише само по теми които задоволяват само твоя интерес.

Светльо
Светльо

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

copy/translate/paste
copy/translate/paste

Връзката към оригиналната статия я поставиха впоследствие!!!
100% съм съгласен, че превода е титаничен труд особено за техническите материи!
А дали съм бастун, не знам в УниБИТ студентите ми не мислят така!
Похвално за автора и екипа, че посочиха първоизточника.!
Статията е по-скоро за раздел хардуер!
Поздрави и дерзайте, на коментиращите и цъкащи минуси, като гламави – недейте се засяга, то интелектуално не всеки може да клони към минус безкрайност!

quake
quake

@copy/translate/paste моите уважения г-н преподавател, но извода че статията е за раздел хардуер ми е непонятен. Относно това на колко потребителя би била полезна статията – предполага се на тези, които използват Windows 10, инсталиран на машина с повече ядра, използващи го за компилация на средни до големи проекти. Тези параметри предполагам са интересни на приличен брой хора, занимаващи се с .NET сферата (един пример на прима виста). А че тук има (почти) неограничен брой интелектуално скопени индивиди е доста точно казано. Дали статията е списана за пълнеж…може и така да е. При всички положения обаче е по-добре от разпалването… Виж още »

Ongo Bongo
Ongo Bongo

Ако съм профи чакащ професионален преводач да ми преведе статийка за бъг в ОС за да пиша код.. по-добре да не пипвам компютър.
Специализирани тематики като тази се четат в оригинал. А отнбосно какво ни се „дава“, качи си един линукс на български, или пък уикипедия..
Това, си е чисто запълване на тематика в сайта.. Това намерили , това превели. Да има аудитория и кликове..

въльо
въльо

е аз съм със 32 ядрен процесор и проблеми до сега съм нямал

AymalieV
AymalieV

Кефи ме, че статията е писана Юли 2017. Сигурно е оправено отдавна, но ние нека си постваме…

мъни
мъни

Многото ядра е просто един тъп маркетинг. Многото ядра не значат по-бърз процесор. Имаше една програмка дето смяташе числото пи в реално време. Е там ти показва кой процесор колко по-бърз е. Лошото е, че като видиш резултата сигурно ще е малко по-добре от един далеч по-евтин и „морално умрял“ процесор.
И за финал: хора, ако искате компютър за сериозна работа или игри – не си купувайте лаптопи. Буквално съм разтапял такова подобие на компютър…

Ибн ебн Ал Хамил
Ибн ебн Ал Хамил

Лаптопите са за хора които пътуват постоянно. Ако всяка седмица си в различен град няма да говориш глупости… Или ще си носиш десктопа като костенурка.

мъни
мъни

до Ибн ебн Ал Хамил
Написал съм „сериозна работа или игри“. Нямам предвид презентацийки, резервации и кореспонденция. Това и телефон вече може да го прави.

Лим Ах Ланеб Нби
Лим Ах Ланеб Нби

Нали си профи.. Що не ползваш Ксен базиран сървър с виртуализация и терминален достъп.. Даже и от таблет може да работиш на големи проекти и да ги смята сървъра а ти през това време да си подхванал следващят проект.. Ей като прочета за динамичните хора дето все пътуват с лаптопа в скута и пишат ли пишат код.. Лятото на рилските езера един седнал и пише ли пише код на един 17″ лаптоп… че имал срокове едни..

Анти-фейк нюз
Анти-фейк нюз

Ако рендираш видео и работиш с професионален софтуер може да чакаш вместо половин час, 10 минути. Това не е за такива като теб, това е за модерен човек, който е креативен, създава неща, а не само да консумира пиратски софтуер, игри и сайтове.

Митко
Митко

А сега дай и поименно двамата такива потребители.

Кольо
Кольо

Всъщност точно това значат, стига поне в началото да не са твърде много. Като научат потребителските версии на вируса, домашната и „PRO“-то да се справят като Server със скалирането, ще стане по-добре. Ако ги научат да скалират като Линукс, ще стане още по-добре. Но все пак „прекаляването“ с ядра, може да има смисъл, когато тренират софтуера, да може някак да заобикаля ограниченията. Тук има описан проблема с утилизацията на много ядра и намаляване коефициента на полезно използуване във връзка с нарастване броят на ядрата. В това число и блокирането на кеша с prefetch данни в клетки на оперативната памет и… Виж още »

Йордан
Йордан

„Многото ядра е просто един тъп маркетинг. Многото ядра не значат по-бърз процесор.“ Напротив, многото ядра означават по-бърз процесор. Да приемем, че една задача се изпълнява за 10часа от едно ядро. То ако същата задача се разпредели между 10 ядра, тя ще бъде свършена за около час. Проблемът е, че да разпределиш една задача да работи върху няколко ядра не е особено лесно. И понеже днес масово софтуерът се пише от програмисти, които не са много на „ти“ с програмирането, се получава така, че задачата се изпълнява само върху едно ядро, вместо върху 10. Защото повечето програмисти само са чували… Виж още »

Кольо
Кольо

Малко по-сложно е отколкото го обясняваш и дори правиш очевидни грешки. Примерно, за да се изпълни задачата върху 10 ядра за 1/10 от времето, за което се изпълнява върху едноядрен процесор, би трябвало всяко от 10-те ядра да е голямо, сложно и 10+% по-производително от едноядреният процесор, с който се прави сравнението.

Colombino
Colombino

Какво искаш да кажеш с изчисляването на числото ПИ?! Ти за това ли си ползваш компа, да смяташ числото Пи. Примерно ако вместо да смяташ Пи, компилираш C++ проект, дали ще ти е маркетинг.
Иначе и в смятането на чила ще те бият многото корове – да кажем, че щом обичаш да смяташ константи, на едното ядро смяташ Пи, на второто ядро смяташ ‘e’, на третото някоя друга константа, … и докато смяташ всичко това си браузиш и чакаш да го сметнат до определен знак. Ще видиш тогава трик ли са ядрата.

Питър Пан
Питър Пан

Като си толкова печен С++ саджия дето все много компилира, ми че наеми си клауд сървър и той да ти смята кода.. Така ще имаш масив и за 10мин ще ти е готов кода.. Или пък си купуваш няколко сървъра, правиш си един клъстър и даже за 5мин си готов.. Да, ама тая карантия някой трябва да я уъправлява правилно. Или искаш да ме убедиш че ако сложа двупроцерно дъно с два ксеона с по 12 ядра и компилатора ще разбие задачите за всяко ядро.. или ще чака ОС да му ги разбите?

Colombino
Colombino

Ползвам, каквото каже клиентът. Ако си компилирам личния проект, едва ли ще ми трябва голяма изчислителна мощ.

mathur
mathur

Аз съм с четири ядрен и нямам проблем….

Човек
Човек

Баси, толкова писане ….и снимки….и диаграми…. и тестове…. за нещо което може да се каже с ЕДНО изричение . Компютъра работи гладко и бързо когато има съвместимост между хардуер, софтуер и операционната система е с подходящи драйвъри . Много фирми и обикновенни тъпаци смятат че като купят най-най скъпото с най-високите параметри старата им счетоводна програмка и офис приложението ще лятят като болиди от формула 1 . Този изключително умен пич да попита чистачката във фирмата как така тази топ компания и е осигурила 48 метли за да чисти бързо офисите а 47 от тях стоят бездействащи в килера а… Виж още »

shmaizera
shmaizera

“Бacи, тoлĸoвa пиcaнe ….и cнимĸи….и диaгpaми…. и тecтoвe…. зa нeщo ĸoeтo мoжe дa ce ĸaжe c EДHO изpичeниe . Koмпютъpa paбoти глaдĸo и бъpзo ĸoгaтo имa cъвмecтимocт мeждy xapдyep, coфтyep и oпepaциoннaтa cиcтeмa e c пoдxoдящи дpaйвъpи . Mнoгo фиpми и oбиĸнoвeнни тъпaци cмятaт чe ĸaтo ĸyпят нaй-нaй cĸъпoтo c нaй-виcoĸитe пapaмeтpи cтapaтa им cчeтoвoднa пpoгpaмĸa и oфиc пpилoжeниeтo щe лятят ĸaтo бoлиди oт фopмyлa 1 . Toзи изĸлючитeлнo yмeн пич дa пoпитa чиcтaчĸaтa във фиpмaтa ĸaĸ тaĸa тaзи тoп ĸoмпaния и e ocигypилa 48 мeтли зa дa чиcти бъpзo oфиcитe a 47 oт тяx cтoят бeздeйcтвaщи в ĸилepa a… Виж още »

Този там
Този там

Виндос и много ядра….ХАХАХАХАХА….

Този там
Този там

Gentoo в единия таб си компилирам хрома в другия кде и си сърфирам из нета на 6 ядра.Твоя процесор е нещо менте.

Georgio
Georgio

Microsoft в момента мисли как да изкара още повече пари !
Милиардите, може би вече не са им достатъчни.
примерно: „Microsoft тества пускането на реклами в Mail приложението на Windows 10“

Хъцъмъцъ
Хъцъмъцъ

А ве много ти е слаб процесора вземи си по-мощен хахаха

Мммдаааа
Мммдаааа

И при мен се получават такива неща но само когато не съм го чистил или не съм дефрагментирал харда и това се оправя ама тоя много си е играл да следи процесите