Помилка Windows 10: початок історії

Нещодавно команда Vivaldi повідомила про серйозну проблему продуктивності Windows 10 в Chromium. Вона виявила, що проблема була викликана функцією безпеки Windows, яка корисна для захисту додатків, таких як браузер. Ось історія про цю подію.

Нещодавно ми вирішили додати тестерів Windows 10 в наш кластер модульних тестів Windows, який використовував Windows 7 Pro.

Ми відразу помітили проблеми з продуктивністю. Тестовий набір, який раніше займав близько 100 хвилин, тепер займав 300 або навіть 360 хвилин. Ми спробували вирішити цю проблему шляхом настройки конфігурації ОС, заміни драйверів і налаштування конфігурації віртуальної машини. Нічого не допомогло, і ми повернулися до старого примірника Windows 7 Pro.

Продовжуємо копати

Однак я хотів знати, в чому причина проблеми – середовище віртуальної машини, Windows 10 або щось в тестах і перевіреному коді Chromium або Vivaldi. В цей час я міняв свій шестирічний домашній ПК (який, до речі, був першою машиною, за допомогою якої було скомпільовано вихідний код, який став Vivaldi), і вирішив вилучити свої власні диски з машини і перенести його в офіс, установити новий SSD, інсталювати на нього Windows 10 і виконати кілька тестів.

Я також встановив Win 7 Pro назад в машину.

Перший результат: це безумовно не було середовище віртуальної машини. Один з тестів, який зайняв 100 хвилин при запуску у Windows 10 на цьому комп’ютері, зайняв 20 (двадцять!) хвилин у Windows 7.

Я також провів тести з «сирими» збірками Chromium, щоб з’ясувати, чи була проблема в нашому коді або існувала раніше. Я навіть використовував збірку шестимісячної давнини, щоб перевірити, чи була проблема новою або старою. Я використовував збірку Chromium, щоб дослідити проблему з Mac при використанні bisect.

Після ще кількох випробувань я зв’язався з групою Chromium Ops на їхньому каналі Slack, щоб з’ясувати, чи бачать вони схожі проблеми, навіть якщо вони не досягли таких значень.

Були ознаки деяких відмінностей між Windows 7 і Windows 10, але відмінності невеликі, і їх тестова система сильно відрізняється від нашої. Вони запропонували подати звіт про помилку, що я і зробив.

Провівши додаткове тестування, включно з більш детальним веденням журналу часу виконання тестів, я, нарешті, зміг пов’язати додатковий час з викликом CreateProcess, функцією Windows, використовуваної для запуску нових процесів, яка використовується виконуваними файлами тесту для запуску менших груп тестів, щоб ізолювати їх від основного виконуваного файлу тесту, що означає, що збійні тести не призводять до збою всього набору тестів.

Велике зниження продуктивності

У наборі тестів, який я використовував для свого дослідження, було виконано майже 11 000 тестів в окремих процесах в групах по 10, тому набір тестів викличе близько 1 100 процесів за один запуск тесту.

Я побачив, що в Windows 7 цей крок займав не більше 2-3 мілісекунди, в той час як в Windows 10 він займав не менше 300 мілісекунд, а може бути і 600. І через те, як тестовий код Chromium запускає ці процеси , тільки один тестовий процес може бути запущений одночасно (і кінець обробки групи тестів також повинний розташовуватися в одному і тому ж рядку), тому для запуску 8 процесів буде потрібно не менше 2,4 секунди, і тільки тоді результати групи тестування, яка зазвичай для обробки і обробки треба було всього 100 мілісекунд (тобто перша тестова група після запуску протягом 100 мілісекунд повинна була чекати не менше 2300 мілісекунд, перш ніж її слот міг починатися зі наступної групи). Це значне зниження продуктивності.

В цей час Брюс Доусон з команди Chromium почав вивчати проблему. Хоча він спочатку підозрював іншу проблему, він швидко виявив, що проблема була викликана функцією безпеки Windows, званій Control Flow Guard (CFG), і що час, що використовується Windows для ініціалізації цієї проблеми, очевидно, збільшився з КВАДРАТОМ числа функцій в виконуваному файлі (якщо подвоїти кількість функцій, час збільшується в чотири рази).

Ця функція дуже корисна для захисту таких додатків, як браузер, але насправді не обов’язкова для тестових виконуваних файлів, тому він обійшов проблему в тестовому виконуваному файлі, відключивши для них функцію, яка раніше використовувалася всіма виконуваними файлами Windows.

Потім він відіслав м’яч в Microsoft, оскільки наявність важливої функції з «квадратичним» часом не дуже гарна річ, тому він підозрював, що це помилка. Протягом декількох днів розробники Microsoft повідомили, що вони виправили проблему.

Можливо, це проблема для нормального використання браузера

Можливо, ця проблема також впливає на нормальне використання браузера, оскільки і Chrome, і Vivaldi запускають нові процеси для кожної вкладки, але значна частина фактичного коду знаходиться в DLL, загальних для процесів, і конфігурація Windows CFG повторно використовується для DLL. Це може бути не так помітно при нормальному використанні.

Навіть якщо це викликає деякі проблеми з продуктивністю, відключення функції безпеки не варіант.

Подібні проблеми з продуктивністю можуть вплинути як на продуктивність продукту, так і на час виконання розробки. Команда Chromium компілює і запускає всі оновлення через набір тестів, перш ніж вони будуть прийняті в основну базу коду, тому затримки тут можуть призвести до затримок в тому, як швидко вони зможуть отримувати оновлення. Тому важливо знайти і виправити проблеми з продуктивністю.

Сподіваємося, що патч від Microsoft повинен усунути проблему. Помилку було виправлено минулого тижня, тому ми очікуємо, що вона буде в наступному патчі у вівторок.

Це не перша проблема продуктивності, про яку повідомили

Це друга проблема продуктивності, про яку ми нещодавно повідомляли. Попередній випадок був регресією на деяких з наших Mac-тестерів. Це сталося через те, що код бази даних усередині стежив за тим, щоб всі дані записувалися на диск, а Mac OS використовувала для цього дуже повільний метод. Це було особливо повільно на машинах, які використовують повільні диски, такі як наш тестер. Після того, як ми зв’язалися з командою Chromium, вони виявили, що їх тести теж сповільнилися, але не на таку ж величину, як ми спостерігали. З’ясування причини дійсно передбачало, що, можливо, код бази даних був занадто агресивний при виконанні такого роду синхронізації диска, і вони вивчають це. Однак це делікатна проблема, оскільки в разі втрати живлення важливо забезпечити правильне зберігання бази даних на диску. Тим часом ми змогли обійти цю проблему при запуску наших тестів.

Дослідження проблеми Windows 10 триває

Проблема продуктивності Windows 10 все ще досліджується. Брюс Доусон виявив, принаймні, одну серйозну проблему в групі тестів, коли він працював над проблемою CFG, і він також знайшов кілька інших проблем. Я також помітив, що продуктивність Windows 10 все ще не зовсім збігається з Windows 7, тому, ймовірно, є ще проблеми, які необхідно виявити. Хоча вони можуть бути не такою великою проблемою, як проблема CFG, вони все ж можуть вказувати на проблеми, які також впливають на браузер. Ми не дізнаємося, поки не знайдемо їх.

Таким чином, в майбутньому в Chromium може бути зареєстровано більше помилок продуктивності.


Джерело: vivaldi.com
Текст: Yngve Pettersen – розробник та експерт з безпеки в команді Vivaldi
Переклад: Kurai

Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.