Ubuntu зависает при пиковой нагрузке на ОЗУ
Меня часто раздражает Ubuntu, когда в оперативной памяти наблюдается пик - например, при запуске эмулятора Android Studio или при зависании вкладки Chrome - весь графический интерфейс зависает, и поэтому я вынужден либо ждать его возвращения, либо идти TTY и убить преступника.
Возможно ли, что Ubuntu управляет оперативной памятью совсем иначе, чем Windows? В Windows само приложение зависает, но не весь графический интерфейс. Есть ли способ заставить Ubuntu вести себя как Windows в этом отношении?
2 ответа
Современные ОС используют пейджинг для управления памятью. Это дает системе некоторые преимущества, такие как возможность использовать больше памяти, чем у вас физически, защищая некоторую чувствительную область памяти (например, зарезервированную память ядра), помимо прочего, на которую я могу сослаться, если вы хотите узнать больше о подкачке.
Но что такое пейджинг?
Я пропущу технические подробности и приведу аналогию. Представьте, что у вас есть коллекция энциклопедий, от А до Я, и, будучи любопытным человеком, вы любите проводить ее во второй половине дня, читая ее. Вы держите все энциклопедии на своей книжной полке, и у вас есть стол для чтения, на котором можно разместить 4 книги.
Однажды вы читаете о "Парусном спорте", о котором написано в энциклопедии буква S. В какой-то момент вам может понадобиться прочитать что-то еще, например, "Ветры" в букве W книги. Пока он у вас на столе для чтения, вы можете быстро открыть его и прочитать то, что вам нужно, а затем вернуться к книге "Парусный спорт". Проблема в том, что ваш стол для чтения может вместить только 4 книги, и велика вероятность, что вам понадобится книга, которой еще нет. Затем вам нужно будет взять одну из книг со стола обратно на полку, взять книгу, которая вам нужна, к столу для чтения и прочитать ее.
Хорошо, как эта целая книжная история связана с моими замораживаниями? Ну, компьютер делает что-то подобное все время. Чтобы иметь возможность использовать больше памяти, чем физически, компьютер делит память на страницы, которые представляют собой небольшие непрерывные блоки памяти. Они не должны постоянно находиться в оперативной памяти ("таблица чтения"), они могут храниться на вашем диске ("книжная полка"). Если ОЗУ заполнено, и ЦПУ требуется для чтения / записи на этих страницах, хранящихся на диске, одна из страниц в ОЗУ будет сохранена на диске, а запрошенная страница будет загружена в ОЗУ.
Это работа ядра, поэтому она прозрачна для пользователя и программ. Но поскольку чтение и запись на диск намного медленнее, чем чтение и запись в ОЗУ, вы заметите эти зависания.
В Linux есть раздел под названием swap, который используется для хранения этих дополнительных страниц. Windows делает то же самое, но я думаю, что он использует файл. Само ядро системы не будет зависать, так как оно будет на заблокированных ("не подлежащих замене") страницах.
Изображение ниже (из статьи в Википедии) иллюстрирует концепцию подкачки (и виртуальной памяти, в которую нам не нужно вдаваться). Эти блоки представляют страницы, размещаемые как в памяти, так и на диске.
Я полагаю, что причина, по которой это может выглядеть так, будто Linux тоже зависает, заключается в том, что Unity (графический интерфейс рабочего стола) может испытывать задержки, вызванные этой заменой, в то время как в Windows они могут сохранять код графического интерфейса рабочего стола на заблокированных ("не заменяемых") страницах., Это всего лишь теория мозгового штурма.
У меня были подобные проблемы в прошлом. Я изменил swappiness в Ubuntu, чтобы ОС записывала RAM на HD намного позже.
Прочтите ответ по изменению перестановки здесь: Как мне настроить перестановку?
Я не могу гарантировать, что это поможет решить вашу проблему, но, на мой взгляд, это лучшая ставка.