Укрепляем GNOME — дело о пропавшей памяти и неучтенных картинках

Материал из Rosalab Wiki
Перейти к: навигация, поиск
м (moved Blog:Точка Росы/Укрепляем GNOME — дело пропавшей памяти и неучтенных картинках to [[Blog:Точка Росы/Укрепляем GNOME — дело о пропавшей памяти ...)
 
(Batch edit: replace [[../ with [[Blog:Точка Росы/)
 
(не показано 7 промежуточных версий 3 участников)
Строка 1: Строка 1:
 
<!-- Смело пишите здесь свою заметку. Можно использовать все возможности вики, включать картинки и другие статьи — все они автоматически отреплицируются наружу -->
 
<!-- Смело пишите здесь свою заметку. Можно использовать все возможности вики, включать картинки и другие статьи — все они автоматически отреплицируются наружу -->
  
[[../Тук-тук, откройся, или решена проблема входа в GNOME после засыпания|Продолжим тему]] невидимых, но очень полезных доделок и исправлений GNOME.
+
[[Blog:Точка Росы/Тук-тук, откройся, или решена проблема входа в GNOME после засыпания|Продолжим тему]] невидимых, но очень полезных доделок и исправлений GNOME.
  
 
Ведь на поверхности, что всплывает в разных обзорах — это фичи, внешний вид, обои и иконки, … а реально пользователей в первую очередь беспокоит надежность работы системы, чтобы работало без глюков и торможений месяцами.
 
Ведь на поверхности, что всплывает в разных обзорах — это фичи, внешний вид, обои и иконки, … а реально пользователей в первую очередь беспокоит надежность работы системы, чтобы работало без глюков и торможений месяцами.
Строка 8: Строка 8:
 
Но современный пользовательский подход — работа без перезагрузки, чтобы не терять открытых окон программ, контекстов работы, и десктоп-лептоп не выключается в перерывах, а только засыпает или гибернируется.  
 
Но современный пользовательский подход — работа без перезагрузки, чтобы не терять открытых окон программ, контекстов работы, и десктоп-лептоп не выключается в перерывах, а только засыпает или гибернируется.  
  
Поэтому любые утечки памяти достаточно критичны — ведь стоит оболочке «наестся памяти», система «зароется в своп», все начнет дико тормозить и придется перегружаться, как в давно забытые времена.
+
Поэтому любые утечки памяти достаточно критичны — ведь стоит оболочке «наесться памяти», система «зароется в своп», все начнет дико тормозить и придется перегружаться, как в давно забытые времена.
  
Мы серьезно подходим к тестированию клиентских систем, и если говорить о «нагрузочном тестировании» тут наверно некорректно, поэтому мы проводим, как мы это называем, «марафонское тестирование» — автоматическое и ручное тестированием системы в течении недель с непрерывным воспроизведением различных сценариев — это и броузер с флеш-видео с ютубом, это и поочередный запуск абсолютно всех установленных программ.
+
Мы серьезно подходим к тестированию клиентских систем, и если говорить о «нагрузочном тестировании» тут, наверное, некорректно, поэтому мы проводим, как мы это называем, «марафонское тестирование» — автоматическое и ручное тестированием системы в течении недель с непрерывным воспроизведением различных сценариев — это и браузер с флеш-видео с ютубом, это и поочередный запуск абсолютно всех установленных программ.
  
И при этом тестировании мы начали получать неприятные сигналы — тестировщики жаловались, что «этот ваш GNOME есть память, как не в себя».
+
И при этом тестировании мы начали получать неприятные сигналы — тестировщики жаловались, что «этот ваш GNOME ест память, как не в себя».
Мы сделали специальную сборку, прошитую Valgrindом и мучали ее неделями — но никак не могли найти серьезных зарегистрированных утечек.
+
Мы целыми днями мучили gnome-shell Valgrind'ом — но никак не могли найти серьезных зарегистрированных утечек.
Однако еженочное автоматическое тестирование, запускавшее все пользовательские программы, включая кучу игр, подтвердило сигналы тестировщиков система в какие-то моменты подьедала память, и часто при тестах, когда система съедала больше четырех гигов падала тестирующая виртуалка.
+
Однако автоматическое тестирование, запускавшее все пользовательские программы, включая кучу игр, подтвердило сигналы тестировщиков: система в какие-то моменты подъедала память, и часто при тестах, когда система съедала больше четырех гигов, падала тестирующая виртуалка.
  
Все это выглядело, как будто вроде как добротный сборщик мусора GNOME, не спешил отдавать память.
+
[[File:iceberg-js.svg|480px|right]]
  
Похожие вещи наблюдались в куче дистрибутивов, гномовцем сталиви баги, на которые они писали отписки в духе «это не мы, это ваши графические драйвера виноваты», так что нам пришлось прорыватся самим.
+
Все это выглядело, как будто вроде как добротный сборщик мусора GNOME не спешил отдавать память.
 +
 
 +
Похожие вещи наблюдались в куче дистрибутивов, гномовцам ставили баги, на которые они писали отписки в духе «это не мы, это ваши графические драйвера виноваты», так что нам пришлось прорываться самим.
  
 
Ловили эту проблему несколько итераций, … опустим грустные и неинтересные сложности, расскажем о некоторых выявленных причинах.  
 
Ловили эту проблему несколько итераций, … опустим грустные и неинтересные сложности, расскажем о некоторых выявленных причинах.  
  
Например, внутри Javascriptовой логики (в background.js), создавался внутренний джаваскриптовый кеш-словарь картинок-обоев, причем картинка создавалась для каждого разрешения. В результате, часть программ, особенно которые перехватывали весь экран, как игрушки, в этом кеше происходило накопление картинок.  
+
Например, внутри Javascript'овой логики (в background.js), создавался внутренний джаваскриптовый кеш-словарь картинок-обоев, причем картинка создавалась для каждого разрешения. В результате, часть программ, особенно которые перехватывали весь экран, как игрушки, в этом кеше происходило накопление картинок.  
  
 
Теоретически, Garbage Collector от GNOME должен был удалять неиспользуемые картинки, но. Этого не происходило из-за тонкостей биндинга JavaScriptoвой логики с C-шными библиотеками — GC просто не видел, и не учитывал память, занимаемую картинками, учитывая только JavaScriptовые структуры ссылающиеся на них.  
 
Теоретически, Garbage Collector от GNOME должен был удалять неиспользуемые картинки, но. Этого не происходило из-за тонкостей биндинга JavaScriptoвой логики с C-шными библиотеками — GC просто не видел, и не учитывал память, занимаемую картинками, учитывая только JavaScriptовые структуры ссылающиеся на них.  
 
Да, если бы он освободил их — то освободилась бы и захваченная на «C»-уровне память, но т.к. он эту память не учитывал, то он и не спешил со сборкой мусора и освобождением.
 
Да, если бы он освободил их — то освободилась бы и захваченная на «C»-уровне память, но т.к. он эту память не учитывал, то он и не спешил со сборкой мусора и освобождением.
  
В результате, мы внесли пару точечных патчей именно в JavaScriptовую логику ([https://abf.rosalinux.ru/import/gnome-shell/commit/fac8c571bd5ecf9358324143c208ced0e67360eb], [https://abf.rosalinux.ru/import/gnome-shell/commit/9e43e13f91789c348a042ec90f19738713efb46f]), и эта проблема ушла.
+
В результате, мы внесли пару точечных патчей именно в JavaScriptовую логику, и эта проблема ушла.
 +
 
  
 
Так что знайте — в нашем дистрибутиве мы не только впиливаем красоту и фичи, но и серьезно исследуем проблемы надежности — к сожалению, там еще есть что копать.
 
Так что знайте — в нашем дистрибутиве мы не только впиливаем красоту и фичи, но и серьезно исследуем проблемы надежности — к сожалению, там еще есть что копать.
Строка 44: Строка 47:
 
<!-- Когда статья будет готова к публикации, сотрите эту строчку и раскомментируйте следующую -->
 
<!-- Когда статья будет готова к публикации, сотрите эту строчку и раскомментируйте следующую -->
 
[[Category:ToROSAPoint]]
 
[[Category:ToROSAPoint]]
 +
{{wl-publish: 2014-01-20 11:01:45 +0400 | Stanislav.fomin }}
 +
[[Category:GNOME UX Fixes]]
 +
[[Category:GNOME Fix]]

Текущая версия на 18:55, 26 мая 2015


Продолжим тему невидимых, но очень полезных доделок и исправлений GNOME.

Ведь на поверхности, что всплывает в разных обзорах — это фичи, внешний вид, обои и иконки, … а реально пользователей в первую очередь беспокоит надежность работы системы, чтобы работало без глюков и торможений месяцами.

Да, месяцами, хотя казалось бы месячный аптайм нужен только серверным системам, пользователям же надо спать и все-такое. Но современный пользовательский подход — работа без перезагрузки, чтобы не терять открытых окон программ, контекстов работы, и десктоп-лептоп не выключается в перерывах, а только засыпает или гибернируется.

Поэтому любые утечки памяти достаточно критичны — ведь стоит оболочке «наесться памяти», система «зароется в своп», все начнет дико тормозить и придется перегружаться, как в давно забытые времена.

Мы серьезно подходим к тестированию клиентских систем, и если говорить о «нагрузочном тестировании» тут, наверное, некорректно, поэтому мы проводим, как мы это называем, «марафонское тестирование» — автоматическое и ручное тестированием системы в течении недель с непрерывным воспроизведением различных сценариев — это и браузер с флеш-видео с ютубом, это и поочередный запуск абсолютно всех установленных программ.

И при этом тестировании мы начали получать неприятные сигналы — тестировщики жаловались, что «этот ваш GNOME ест память, как не в себя». Мы целыми днями мучили gnome-shell Valgrind'ом — но никак не могли найти серьезных зарегистрированных утечек. Однако автоматическое тестирование, запускавшее все пользовательские программы, включая кучу игр, подтвердило сигналы тестировщиков: система в какие-то моменты подъедала память, и часто при тестах, когда система съедала больше четырех гигов, падала тестирующая виртуалка.

Iceberg-js.svg

Все это выглядело, как будто вроде как добротный сборщик мусора GNOME не спешил отдавать память.

Похожие вещи наблюдались в куче дистрибутивов, гномовцам ставили баги, на которые они писали отписки в духе «это не мы, это ваши графические драйвера виноваты», так что нам пришлось прорываться самим.

Ловили эту проблему несколько итераций, … опустим грустные и неинтересные сложности, расскажем о некоторых выявленных причинах.

Например, внутри Javascript'овой логики (в background.js), создавался внутренний джаваскриптовый кеш-словарь картинок-обоев, причем картинка создавалась для каждого разрешения. В результате, часть программ, особенно которые перехватывали весь экран, как игрушки, в этом кеше происходило накопление картинок.

Теоретически, Garbage Collector от GNOME должен был удалять неиспользуемые картинки, но. Этого не происходило из-за тонкостей биндинга JavaScriptoвой логики с C-шными библиотеками — GC просто не видел, и не учитывал память, занимаемую картинками, учитывая только JavaScriptовые структуры ссылающиеся на них. Да, если бы он освободил их — то освободилась бы и захваченная на «C»-уровне память, но т.к. он эту память не учитывал, то он и не спешил со сборкой мусора и освобождением.

В результате, мы внесли пару точечных патчей именно в JavaScriptовую логику, и эта проблема ушла.


Так что знайте — в нашем дистрибутиве мы не только впиливаем красоту и фичи, но и серьезно исследуем проблемы надежности — к сожалению, там еще есть что копать.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^43
65%
Порадовала :)18
27%
Оставила равнодушным -_-2
3%
Огорчила :(3
5%

[ Хронологический вид ]Комментарии

Не нашёл ссылки на багрепорт (с патчем?) в bugzilla.gnome.org.

Войдите, чтобы комментировать.