The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз свободного web-браузера QupZilla 1.6.0, построенного н..., opennews (??), 02-Янв-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


22. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +2 +/
Сообщение от arisu (ok), 02-Янв-14, 14:38 
> Да уж, вчера опять обратил внимание - в Файрфоксе открыто 10 вкладок,
> в основном технического характера, половина даже без картинок и на Ютубе
> две — одна с поиском, другая с видео. Я запустил Блендер
> и всё стало жутко свопиться (файл тяжелый но не настолько). Посмотрел
> в мониторе и офигел лиса отъела 900 МБ! И это не
> считая флэш-плагина.

но КАК? пять табов, десятка два дополнений, 180 мегов памяти занято. или вы там все вместо RES на VIRT смотрите? или я даже не знаю, что с пандой делаете.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

69. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от pv47 (ok), 02-Янв-14, 21:57 
> или вы там все вместо RES на VIRT смотрите?

Не знаю, на что _они_ смотрят, но, может, разовьёте мысль, почему стоит смотреть не на то, сколько памяти браузер выделил (VIRT), а на то, сколько он успел занять на данный момент (RES)?

И почему считается нормальным выделять в разы больше памяти, чем реально требуется (вы же на это намекаете), так что в случае реальной нехватки памяти вместо проверки приложением возвращаемого malloc значения и внятного сообщения об ошибке происходит oom killer ядром случайно выбранного приложения?

Ответить | Правка | Наверх | Cообщить модератору

74. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от arisu (ok), 02-Янв-14, 23:32 
> Не знаю, на что _они_ смотрят, но, может, разовьёте мысль, почему стоит
> смотреть не на то, сколько памяти браузер выделил (VIRT), а на
> то, сколько он успел занять на данный момент (RES)?

вот именно потому, что зарезервировать можно вплоть до верхнего лимита, и это совершенно не значит, что программа собралась именно столько использовать.

> И почему считается нормальным выделять в разы больше памяти, чем реально требуется

потому что так намного удобней писать memory managers. намного проще (и быстрее, кстати) зарезервировать большой кусок при помощи brk или anonymous mmap, и потом разбивать его на куски уже средствами memory manager (от того же libc, например), чем на каждый malloc() дёргать ядро. к тому же гранулярность выделения у ядра страничная, так что всё равно придётся страницы на куски бить.

теперь понятно?

Ответить | Правка | Наверх | Cообщить модератору

76. "Релиз свободного web-браузера QupZilla 1.6.0,..."  –1 +/
Сообщение от pv47 (ok), 03-Янв-14, 01:11 
> и это совершенно не значит, что программа собралась именно столько использовать.

... и уж тем более это не значит, что программа НЕ собралась столько использовать

> потому что так намного удобней писать memory managers.

Должен быть разумный (читай: настраиваемый пользователем) предел. Когда программа выделяет 50МБ вместо 5 это разумно. Когда она выделяет 2ГБ вместо 200МБ - это бред.

Но речь не об этом.

Когда менеджер памяти "выделил" себе 2ГБ, то и считать за "использованное" надо 2ГБ, а не 200МБ, которые "сейчас" использованы. Если у меня две программы, каждая из которых "выделила" по 2ГБ и использует по 200МБ, а в системе 2ГБ физической памяти, полагать, что у меня занято 400МБ, небезопасно. В любой момент программы могут начать использовать выделенную память и одна из них будет убита oom killer. Особенно в наше время, когда все пытаются использовать GC и освобождать память не тогда, когда она больше не нужна, а когда не получается больше выделить.

VIRT даёт более адекватное представление о потенциальных запросах приложения на память.

Ответить | Правка | Наверх | Cообщить модератору

80. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от Аноним (-), 03-Янв-14, 02:36 
> Особенно в наше время,

В наше время вообще все небезопасно...

Тут есть два варианта - первый, поставь лимит на память, чтобы враги не съели и не довели до oom, cgroups тебе в помощь.

Второй, возьми исходники и пофикси.

Хотя, есть и третий - все время почему-то забываю - можно ведь еще ныть на форумах.

Ответить | Правка | Наверх | Cообщить модератору

99. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от pv47 (ok), 03-Янв-14, 12:46 
> Тут есть два варианта - первый, поставь лимит на память, чтобы враги не съели и не довели до oom, cgroups тебе в помощь.

Спасибо, посмотрю в эту сторону.

Но тут сразу вопрос: cgroups позволяет ограничивать именно объём выделяемой памяти? Я пробовал ulimit, но он позволяет ограничивать лишь объём VIRT, что по описанным arisu причинам (приложения жрут VIRT как не в себя) приводит к печальным последствиям. А ограничение RES в linux не поддерживается.

Ответить | Правка | Наверх | Cообщить модератору

100. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от arisu (ok), 03-Янв-14, 12:49 
> Тут есть два варианта

есть ещё два:
1. вообще спрятать во всех юзерских тулзах VIRT, чтобы бетон не долбили.
2. перестать обращать внимание на горестный плач.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

102. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от pv47 (ok), 03-Янв-14, 13:10 
> 1. вообще спрятать во всех юзерских тулзах VIRT, чтобы бетон не долбили.

Или просто добавить отображение объёма реально выделенной памяти, который можно ограничивать. И наличие которого в системе гарантировало бы, что приложение не упадёт внезапно. То есть, если приложение выделило себе 2ГБ, то оно не будет убито без предупреждения при попытке записи в них.

Но это же слишком трудно, правда? Проще скрыть VIRT. Правда, бетон будут долбить, когда приложения будут падать на ровном месте, оттого что RES внезапно пошло вверх без видимых причин. Но это лишь первое время. Потом привыкнут.

> 2. перестать обращать внимание на горестный плач.

И даже
3. Перестать вообще обращать внимание на пользователей. В случае необходимости докупят ещё памяти, не сломаются. У них же бесконечное число денег. Это мы вынуждены на разработчиках экономить, так как денег мало.

Ответить | Правка | Наверх | Cообщить модератору

104. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от arisu (ok), 03-Янв-14, 13:24 
>> 1. вообще спрятать во всех юзерских тулзах VIRT, чтобы бетон не долбили.
> Или просто добавить отображение объёма реально выделенной памяти

RES и SHR там для кого, а?

> И даже
> 3. Перестать вообще обращать внимание на пользователей.

да, перестать. потому что идиоты, не понимающие, что такое «доступное адресное пространство», «зарезервированное адресное пространство», «эксклюзивно используемая память» и «разделяемая память» — достали. ну не понимаешь, что такое VIRT и зачем оно надо — не смотри туда. вообще. так нет: надо себе нафантазировать ерунды, а потом требовать, чтобы остальные срочно под фантазии подстраивались.

Ответить | Правка | Наверх | Cообщить модератору

166. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от Michael Shigorinemail (ok), 07-Янв-14, 18:53 
>>> 1. вообще спрятать во всех юзерских тулзах VIRT, чтобы бетон не долбили.
>> Или просто добавить отображение объёма реально выделенной памяти

Ну посмотрите smem(1), это не так-то просто.  Почему -- см. пояснения по ссылкам в моём предыдущем ответе Вам только что.

> RES и SHR там для кого, а?

RES ещё более-менее понятно, а SHR само по себе скорее без пользы...

Ответить | Правка | Наверх | Cообщить модератору

167. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от arisu (ok), 08-Янв-14, 00:46 
> RES ещё более-менее понятно, а SHR само по себе скорее без пользы…

ну, человек хотел что-то под названием «реально выделеная память».  и res, и shr показывают именно это. какой запрос — такой и ответ.

Ответить | Правка | Наверх | Cообщить модератору

84. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от arisu (ok), 03-Янв-14, 03:15 
> VIRT даёт более адекватное представление о потенциальных запросах приложения на память.

ну и зачем ты спрашивал пояснений, если все они прошли мимо тебя? неужели так сложно было написать: «я тупой дебил, хоть упоясняйтесь»?

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

89. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от arisu (ok), 03-Янв-14, 09:31 
p.s. вот интересующимся наглядное пояснение, почему я «троллю», а не поясняю внятно что-либо: всё равно пролетает мимо. человек не понял вообще ни слова, а я только зря потратил время. отписка вида «ты идиот» образовательный эффект имела бы точно тот же, развлекательный — намного больше, усилий для написания требует вообще на порядки меньше.
Ответить | Правка | Наверх | Cообщить модератору

101. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от pv47 (ok), 03-Янв-14, 12:59 
> я «троллю», а не поясняю внятно что-либо: всё равно пролетает мимо. человек не понял вообще ни слова

Поменьше агрессии. Я понял, что ты имел ввиду. А ты понял, о чём я написал?

Как внутри приложения можно отследить, что память закончилась, и вместо вызова oom killer сгенерировать, например, симпатичное gui-окошко с сообщением об исчерпании памяти? malloc всегда возвращает успех, т.к. память реально не выделяется, а когда память исчерпывается, процесс получает необрабатываемый SIGKILL.

У Анонима ниже в примере файрфокс заммапил 180МБ icon-theme.cache. Каковы основания предполагать, что в один прекрасный момент он внезапно не захочет использовать (читай: подгрузить в оперативную память) сразу все 180МБ? Ответ "сейчас не подгрузил, значит и никогда не подгрузит" - не ответ.

Ответить | Правка | Наверх | Cообщить модератору

106. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от arisu (ok), 03-Янв-14, 13:28 
> Поменьше агрессии. Я понял, что ты имел ввиду.

нет, не понял.

> А ты понял, о чём я написал?

да. и написал ты ерунду.

> Как внутри приложения можно отследить, что память закончилась, и вместо вызова oom
> killer сгенерировать, например, симпатичное gui-окошко с сообщением об исчерпании памяти?

очень просто: написать memory manager, который будет делать commit сразу по взятию у системы странички. и никогда-никогда не брать у системы больше страниц, чем надо для текущего malloc(). правда, эта фигня будет атомно тормозить, и «радетели за красивое выделение памяти» взвоют ещё громче.

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

Ответить | Правка | Наверх | Cообщить модератору

110. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от pv47 (ok), 03-Янв-14, 14:01 
> не надо с умным видом рассуждать на темы, в которых ты не просто ничего не понимаешь, а вообще несёшь бред в силу странных наркоманских представлений о предмете.

Обещаю, что почитаю про работу памяти в Linux/Unix :) Допускаю, что после этого часть (возможно, и все) вопросов отпадёт.

Но, раз уж мы тут сейчас общаемся, можешь ответить на вопрос про icon-theme.cache? Почему мы можем быть уверены, что выделенные 180МБ адресного пространства не перейдут в RES?

P.S. Свои "наркоманские" представления о предмете я получил, написав минимальную программу на C с использованием malloc и memset и погоняв её несколько раз. Они могут быть неполны, но они проверены экспериментально.

Ответить | Правка | Наверх | Cообщить модератору

117. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от arisu (ok), 03-Янв-14, 15:35 
> Обещаю, что почитаю про работу памяти в Linux/Unix :)

давай после этого и обсуждать.

> P.S. Свои «наркоманские» представления о предмете я получил, написав минимальную программу
> на C с использованием malloc и memset и погоняв её несколько
> раз. Они могут быть неполны, но они проверены экспериментально.

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

Ответить | Правка | Наверх | Cообщить модератору

165. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от Michael Shigorinemail (ok), 07-Янв-14, 18:49 
> Обещаю, что почитаю про работу памяти в Linux/Unix :)

Возможно, пригодится http://linux-mm.org/ActualMemoryFootprint и что-то из:
* http://linuxaria.com/howto/linux-memory-management
** перевод: http://rus-linux.net/MyLDP/sys-conf/memory.html
* http://virtualthreads.blogspot.ru/2006/02/understanding-memo... (2006!)
** перевод: https://www.opennet.ru/base/sys/pmap_memory.txt.html

> Но, раз уж мы тут сейчас общаемся, можешь ответить на вопрос про
> icon-theme.cache? Почему мы можем быть уверены, что выделенные 180МБ
> адресного пространства не перейдут в RES?

Потому что это file backed mmap(2); насколько понимаю как ни разу не специалист по этой области, если туда не пытаться писать (что не должно получиться по режиму открытия файла/правам доступа) -- эти страницы "повиснут" на кэше, а не на процессе.

PS: в смысле если читать, но не писать.

Примерно так же и видеопамять, которая приписываеться X-серверу, не имеет шансов перейти в resident, бишь занятую физическую память.

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

161. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от Michael Shigorinemail (ok), 07-Янв-14, 16:14 
> malloc всегда возвращает успех, т.к. память реально не выделяется, а когда
> память исчерпывается, процесс получает необрабатываемый SIGKILL.

Насколько понимаю, либо проверять при попытке использования (а не выделения), либо отключать overcommit.

> Каковы основания предполагать, что в один прекрасный момент

---
И вот начала Умная Эльза плакать и причитать: «Коли выйду я замуж за Ганса, и родится у нас ребенок, и вырастет он, и пошлем мы его в погреб пива нацедить, вдруг упадет ему на голову кирка и убьет его насмерть».
--- http://mirckazok.ru/view_post.php?id=1069

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

160. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от Michael Shigorinemail (ok), 07-Янв-14, 16:07 
> p.s. вот интересующимся наглядное пояснение, почему я «троллю», а не поясняю
> внятно что-либо: всё равно пролетает мимо. человек не понял вообще ни
> слова, а я только зря потратил время.

Во-первых, пригодиться пояснение может и другим.  Во-вторых -- объяснил кратко и смотришь на то, доходит или нет: если нет, кратенько это прорезюмировал (максимум) и больше времени тратить не стоит.

Кто-то продолжит кинетически тупить об "потенциальные требования", кто-то намотает на ус.

Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

168. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от arisu (ok), 08-Янв-14, 00:48 
в принципе никакого не стоит. «на встречу со звездой надо приходить подготовленным!»
Ответить | Правка | Наверх | Cообщить модератору

87. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от Аноним (-), 03-Янв-14, 08:26 
Потому что VIRT - это объем используемого виртуального адресного пространства, а не реальной физической памяти. В нем, например, учитывается размер открытых mmap-ом файлов, даже если они в памяти не находятся.
Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

90. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от arisu (ok), 03-Янв-14, 09:34 
не пугай страусов, пол бетонный. если кисо ещё не абыделос, оно тебе начнёт рассказывать, что и это неправильно, это всё учитываться не должно. только т-с-с-с, не рассказывай ему про SHR.
Ответить | Правка | Наверх | Cообщить модератору

88. "Релиз свободного web-браузера QupZilla 1.6.0,..."  +/
Сообщение от Аноним (-), 03-Янв-14, 08:37 
>> или вы там все вместо RES на VIRT смотрите?
> Не знаю, на что _они_ смотрят, но, может, разовьёте мысль, почему стоит
> смотреть не на то, сколько памяти браузер выделил (VIRT), а на
> то, сколько он успел занять на данный момент (RES)?
> И почему считается нормальным выделять в разы больше памяти, чем реально требуется
> (вы же на это намекаете), так что в случае реальной нехватки
> памяти вместо проверки приложением возвращаемого malloc значения и внятного сообщения
> об ошибке происходит oom killer ядром случайно выбранного приложения?

Вот, например, top 10 объектов виртуальной памяти моего firefox-а

00007f7f608e0000  30596K r---- icon-theme.cache
00007f7f626c1000  30596K r---- icon-theme.cache
00007f7f94832000  46296K r-x-- libxul.so (deleted)
00007f7e0e600000  50176K rw---   [ anon ]
00007f7e39200000  57344K rw---   [ anon ]
00007f7e243e3000  65540K rw-s- pulse-shm-2215283786
00007f7e46cfb000  65540K rw-s- pulse-shm-4030012202
00007f7f8d2fc000 103568K r---- locale-archive
00007f7f644a2000 182460K r---- icon-theme.cache
00007f7f6f6d1000 182460K r---- icon-theme.cache

Т.е. из них реально в оперативке, дай бог 200 мегабайт находится (из которых 100 - это общая память для pulseaudio), остальные 600 - это отображенные в память файлы, реально память не занимающие.

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру