Qt сколько оперативной памяти
Обновлено: 07.07.2024
Linux – довольно гибкая система, выполнить задачи в которой можно разными способами. Сегодня мы рассмотрим, как узнать, сколько оперативной памяти (ОЗУ — оперативное запоминающее устройство или RAM — Random Access Memory) используется определенным процессом. Сама оперативная память представляет собой специальное устройство, которое используется для временного хранения данных и обеспечивает функционирование ПО.
ОЗУ не стоит путать с ПЗУ (постоянным запоминающим устройством): их отличие заключается в том, что оперативная память является энергозависимой (при выключении компьютера все данные исчезнут), в то время как память жесткого диска сохранит все данные даже после выключения машины. Поэтому и функции, которые они выполняют, также разнятся. Процессор использует оперативную память для быстрого доступа к данным - жесткий диск такую скорость обеспечить не может, поэтому при запуске программа загружается в оперативную память.
Мы отследим занимаемую память на примере процесса веб-сервера Apache.
Команда ps
Первым вариантом будет команда ps, с помощью которой можно получить список процессов, запущенных на сервере.
<PID> - идентификатор процесса, в нашем случае это число 897110.
Получим следующий вывод:
ОЗУ будет представлено в процентном соотношении к общему количеству доступной памяти. К сожалению, в данном примере этот процент крайне мал, и столбец %MEM показывает 0,0.
Команда ps имеет свои ключи, которые вы также можете использовать для удобства:
- -A : все процессы;
- -a : процессы, связанные с конкретным терминалом, кроме главных системных процессов сеанса;
- -d : все процессы, кроме главных системных процессов сеанса;
- T : все процессы на конкретном терминале;
- a : процессы, связанные с текущим терминалом, а также процессы других пользователей;
- r : информация только о работающих процессах;
- x : процессы, отсоединённые от терминала.
Команда top
Второй вариант – использование команды top. Более продвинутые пользователи должны знать эту команду, так как она выводит информацию о нагрузке системы и обновляет ее в реальном времени.
Обратите внимание на столбцы VIRT и %MEM. Последний столбец показывает информацию, которая очень похожа на ту, что получили предыдущей командой. А вот столбец VIRT отображает занятую виртуальную память.
Одним словом, виртуальная память – это некая комбинация ОЗУ и swap, которую использует запущенный процесс.
Обратите внимание, что команда top ограничена размерами окна, из-за чего игнорируется вся информация, которая не помещается на экран.
Получение занятой памяти из /proc
Последней командой для получения занятой процессором памяти будет обращение к псевдофайловой системе /proc.
Снова будет выведен результат, который схож с уже полученным ранее – виртуальная память, используемая процессом веб-сервера Apache.
Вот мы и разобрали на примере процесса Apache способы, которыми можно посмотреть занимаемую память.
Заметил, что любое приложение Qt автоматически отъедает около 2МБ (достаточно лишь вызова QApplication).
Интересно, можно ли это настроить? Искал в троллтеховсой документации и не нашел.
Понятно, что для большого проекта эти мегабайты может и не играют роли, но если куча маленьких, то вместе они жрут огого.
//Вот этого уже достаточно и 2MB нет =)
а разве нельзя создать кутешное приложение (консольное) не создавая экземпляр qapplication?
Ну а если интересует гуишное.
2МБ за простейшую хрень.
А зачем маленьким приложениям гуй?
pmap -d показывай
Причём здесь GUI? В Qt базовый класс это QObject. Чтобы его создать (или вообще сделать любой куте объект) надо подключить библиотеку QtCore. Напрмер в Debian'е sid библиотека libQtCore.so.4.4.3 весит 2 271 276 байт. В винде QtCore4.dll весит 2 662 912 байт (mingw/Qt 4.4.3). Именно они "отъедают" память.
>pmap -d показывай
Я так понимаю последняя строка интересует.
пустое приложение
mapped: 85740K writeable/private: 928K shared: 2072K
пару виджетов(лейбл, кнопка, слайдер, спинбокс)
mapped: 89068K writeable/private: 4236K shared: 2072K
>Причём здесь GUI? В Qt базовый класс это QObject. Чтобы его создать (или вообще сделать любой куте объект) надо подключить библиотеку QtCore. Напрмер в Debian'е sid библиотека libQtCore.so.4.4.3 весит 2 271 276 байт. В винде QtCore4.dll весит 2 662 912 байт (mingw/Qt 4.4.3). Именно они "отъедают" память.
Я не против того, что libQtCore подгружается. Мне не нравится, что создав 50 простеньких приложений, динамически слинкованых, у меня отъелось 200 МБ памяти.
Пересборка qt с оптимизацией по размеру(-Os для gcc/mingw) и отключение С++ exceptions при конфигурации Qt дадут уменьшение размера отъедаемой памяти до 1,5 мб.
Если совсем жалко памяти, то не используйте Qt,а дергайте родное api платформы и не будет расхода памяти. Есть ,в конце концов, Qt for Embedded Linux и Qt Extended.
>Если совсем жалко памяти, то не используйте Qt, а дергайте родное api платформы и не будет расхода памяти.
Жалко. Ну хрен с ним с маком и виндой. А что в линухе прикажете использовать в качестве "родного api"?
А жалко потому, что где же юникс вей? Где идея про много мелких тулз, если каждая будет на ровном месте мегабайты жрать?
Как между собой юникс и qt связаны?
> Я так понимаю последняя строка интересует.
Нет, как раз карта памяти.
libQtCore.so - это shared object, и shared тут не спроста, очень даже не спроста.
Да и еще.. Я не пытаюсь ничего доказать или сказать что-то плохое про Qt. Я лишь хочу разобраться с вопросом.
>Мне не нравится, что создав 50 простеньких приложений, динамически слинкованых, у меня отъелось 200 МБ памяти.
донесу до тебя понятие "shared". shared - это когда один и тот же кусок памяти (код + данные только для чтения) доступен нескольким приложениям, не копируясь между ними. если написано 2мб shared, то каждая следующая прога не грузит заново либу, а юзает уже лежащее, тем самым снижая расход памяти.
Читай, что человек пишет: writeable/private: 4236K
>донесу до тебя понятие "shared". Да знаю я что такое shared. И говорю же.. мне не либы, подгруженые мешают
> И памяти расходет столько же(с точностью до погрешности), сколько одно приложение с одним окном.
Можно в исходниках посмотреть, что там на самом деле происходит, но что-то в говне сегодня ковыряться не охота.
Не понимаю. Чего вы хотите добиться в стиле "много мелких тулз"? Много мелких гуи тулзов? Это явно не юниксвэй, а херня какая-то. Тут проще сделать всё в одном. А вот если делать консольные приложения Qt, то они явно не будет отбирать столько памяти. А делать их ессно надо не с помощью QApplication, а с QCoreApplication. Вообщем читать RTFM.
Нуну. есть с десяток прог. Каждая делает что-то одно и не зависит от других. Возможно будут все 10 использоваться вместе, возможно нет. Пихать их все в одно - маразм. И отдавать с 50МБ под это дело тоже. И жа они гуи. тут все-равно юникс_вей/не_юникс_вей, а объединять их в одно - маразм.
Млин зайка тебе же сказали
либа шареная то бишь все твои 50 прог
будут юзать один и тот-же кусок памяти с либой,
а не каждая +2 метра.
А память которая выделяеться малоком
под что-то, сделай трейс и посмотри сколько ее и зачем,
в любом случае ГУЙ ЖРЕТ ПАМЯТЬ и от этого никуда не деться.
Хочешь экономить память пиши на С под консоль, юзай глибс
и забудь про всякие жирные либы.
О дорогой анонимус, ты дурак или читать не умеешь?
Если второе, то читай:
>mapped: 89068K writeable/private: 4236K shared: 2072K
Если и сейчас не видишь, то 4236K. Да.. 4МБ НЕ ШЕАРД.
> Заметил, что любое приложение Qt автоматически отъедает около 2МБ
Пустое приложение на Свинг отъедает 22М и ничего :)
Скажу так. QT очень много какой статический информации тащит.
Два - не забываем, что qt и С++ несколько не близкие концепции. Поэтому многие вещи из С++ qtшники дублируют, и жрут этим память хорошо. Поэтому оптимизация под размер может что-то и дать, но немного.
Да и треть. Эта очередь --- штука хиртая. На чем она точно реализована - не знаю. Ну думаю что просто основной API для реализации этого может откушать хорошо..
ЗЫ: да и забыл. Да. Под каждое окно выделяется backbuffer для отрисовки
Ну что-ж всем большое спасибо. =)
ЗЫ я вообще думал на питоне писать. Дык вместе с интерпритатором это выливается в 10МБ =))
Я занимаюсь встроенным проектом linux + qt, и мне было интересно, каково базовое потребление памяти ядром Linux плюс некоторые базовые службы. Этого достаточно, чтобы запустить какое-нибудь приложение на основе фреймбуфера.
Может ли кто-нибудь указать мне на более подробный ресурс по этой теме?
2 ответа
Цифры в приведенной вами таблице выглядят разумно.
Фактический ответ - «это зависит от обстоятельств». Да, Вирджиния: возможно иметь работающую ОС и графический интерфейс на основе Qt менее чем в 4 МБ.
Фактическое использование памяти будет сильно отличаться в зависимости от:
- Какое ядро вы используете
- Как вы настраиваете сборку ядра
- Какие драйверы ядра вы загружаете во время выполнения
- Что вы запускаете во время инициализации системы
- И т. Д. И т. Д.
ТАКЖЕ: вот список готовых дистрибутивов с графическим интерфейсом, которые работают на Pentium IV с 512 МБ ОЗУ:
Я бы посоветовал использовать Yocto для таких сборок, но вы также можете взглянуть на предстоящий проект «Boot to Qt», который является базовой заменой Qt 5 для Qt, встроенного в Qt 4. Я бы не советовал заглядывать в ссылку, которую вы вставили. ваш вопрос.
Вам обязательно стоит сосредоточиться на Qt 5 по нескольким причинам. В первую очередь, вероятно, потому, что вы можете получить аппаратное ускорение, а Qt получил широкое применение для встраиваемых систем, включая развязку модуля QtWidgets и так далее.
Здесь вы можете найти превью технологии, над которой работают эти парни из Норвегии. Это просто для справки в будущем:
Я бы сейчас начал использовать проект Yocto. Мы работали над слоем «meta-qt5», который не идеален, но достаточно хорош. Yocto также позаботится о Linux с «минимальными образами» и так далее.
Не уверен, что вы видели классический пример пару лет назад, но была «загрузка Qt» для встроенной платы Linux, которая произошла в течение секунды. Вот ссылка на материалы для чтения. К сожалению, исходное видео больше не доступно.
Привет Пикабу! Последние несколько лет в сети разгораются жаркие споры о том, нужна ли быстрая память игровому ПК и так ли важны ее тайминги. В этой статье мы расскажем, стоит ли так внимательно смотреть на тайминги и какая частота оптимальна, а так же сколько ОЗУ нужно именно вам. Как всегда - текстовая версия под видео.
В случае с процессорами AMD Ryzen все понятно — там внутренняя шина напрямую зависит от частоты ОЗУ, так что чем последняя больше, тем быстрее передаются данные между кластерами ядер и тем быстрее работает CPU.
Но в случае с Intel такого нет, кольцевая шина этих процессоров не зависит от частоты ОЗУ. К тому же большая часть игровых ноутбуков работает на медленной памяти с частотой 2400-2666 МГц без каких-либо проблем в играх, как и многие относительно старые топовые Core i7, которые вообще пашут вместе с DDR3 на частоте 1600 МГц и в ус не дуют. Чтобы этот обзор был полезен обоим лагерям, мы расскажем, так ли нужна быстрая память для современного игрового ПК на процессоре Intel, нужно ли так внимательно обращать внимание на тайминги и сколько оперативной памяти нужно современному ПК для игр и работы. Посмотрим, так ли нужны низкие тайминги, и как FPS в тяжелых играх зависит от частоты ОЗУ.
Минутка теории
В этой статье мы будем рассматривать реальную игровую систему с реальными настройками графики. Иными словами, не будет никаких тестов в HD с минимальным пресетом, чтобы максимально нагрузить процессор — все игровые бенчмарки прогонялись в народном разрешении 1920х1080 на максимальных настройках, чтобы упор был именно в видеокарту. В противном случае, если упор идет в процессор, низкий FPS будет еще терпимой проблемой — вы скорее всего будете получать фризы и непрогруженные текстуры. Конечно, если вы суровый челябинский геймер, едва ли это вас остановит, но мы все же рассматриваем реальные игровые условия.
Также мы рассматриваем ситуацию, когда видеокарте хватает собственной памяти — в противном случае вы опять же можете столкнуться с проблемами производительности в играх, и быстрая ОЗУ едва ли вас спасет, потому что она все еще будет чуть ли не на порядок медленнее видеопамяти. Перейдем к тестовой системе.
Что будет, если задрать тайминги в облака?
Первое, что мы проверим — что будет, если мы очень сильно увеличим тайминги ОЗУ. Что же это такое? По сути оперативная память — это набор ячеек, которые могут хранить 0 или 1. Однако процессору, чтобы добраться до определенной ячейки, нужен ее точный адрес — банк памяти, строка и столбец. Тут все очень похоже на реальные адреса — на письме вы должны указать город, улицу, дом и лишь потом только квартиру.
При это процессор — очень ответственный почтальон, он должен точно знать, сколько у него займет по времени обращение к определенной ячейке. И как раз это время и есть тайминг, и всего выделяют 4 основных или первичных, а также с десяток вторичных и нередко под полсотню третичных. Максимальный вклад в быстродействие памяти дают именно первичные тайминги, поэтому именно их мы и будем рассматривать.
И, очевидно, чем тайминги меньше, тем быстрее процессор сможет добираться до нужных ячеек и тем быстрее он будет работать с ОЗУ, поэтому выглядит разумным покупать тот комплект памяти, у которого минимальные задержки на своей частоте.
Итак, тест памяти и кэша в AIDA64 показал, что при таком завышении таймингов слегка снизилась скорость копирования и на 10% увеличилась задержка доступа к ОЗУ. Последнее как раз и было ожидаемо с учетом того, что мы сильно увеличили тайминги, но в общем и целом падение сложно назвать катастрофическим.
Ладно, а как себя поведет игра World War Z на API Vulkan? Он низкоуровневый и в теории может лучше работать с железом. Но и здесь разницы нет — что с оптимизированными, что с задранными таймингами FPS непоколебим и составляет 180.
Может в Far Cry New Dawn картина изменится, как-никак эта игра не очень хорошо оптимизирована под многопоток? И да, разница действительно есть, но ее сложно назвать значительной — средний FPS при увеличении таймингов снизился с 125 до 122, то есть лишь на 2%.
Какой отсюда можно сделать вывод? Даже если поставить откровенно гипертрофированные тайминги, разница в FPS минимальна или ее нет совсем. С учетом того, что продающиеся наборы ОЗУ нередко уже из коробки имеют неплохие тайминги для своей частоты, нет никакого смысла переплачивать за дорогие комплекты с небольшими задержками — вы едва ли уловите разницу в FPS. И это же, в теории, касается процессоров AMD.
Почему так происходит? Все просто — подавляющее большинство современных и не очень процессоров и имеют по три или даже четыре уровня кэша. И информация из ОЗУ заранее пишется в кэш, и лишь потом с ней работает CPU. А с учетом того, что кэша третьего уровня много, нередко пара десятков мегабайт, влияние задержек доступа к памяти становится минимальным.
Играемся с частотой памяти
Окей, а есть ли вообще смысл в большой частоте ОЗУ? Мы решили проверить три варианта. Первый — это DDR4-2133, минимальная пользовательская частота для последнего поколения памяти. Да, вы можете сказать, что большая часть процессоров даже на неразгонных платах поддерживает частоту хотя бы 2400 МГц, но мы решили пойти по самому минимуму и рассмотреть вариант, когда в компьютере стоит самая дешевая память с AliExpress.
Второй вариант — это DDR4-2933. Именно такую память способны поддерживать современные процессоры Intel Core 10-ого поколения, они же Comet Lake, на всех платах даже без разгона. С учетом того, что возможности по оверклокингу у таких процессоров чисто номинальные и вы от силы получите несколько лишних процентов производительности, возникает вопрос — а есть ли вообще смысл переплачивать за платы на чипсете Z490, раз CPU почти не гонится, и остается только разгон памяти?
Ну и третий вариант — это текущая конфигурация на DDR4-3400. Такая частота доступна подавляющему большинству современных процессоров Intel, даже если это урезанные Core i3, при этом планки на ней стоят вменяемых денег.
Для начала — все тот же тест ОЗУ из AIDA64. Тут уже падение скоростей чтения и записи сложно назвать слабым — шутка ли, DDR4-3400 быстрее стоковой DDR4-2133 в полтора раза. А вот задержки увеличились не очень сильно, приблизительно на 20% — сказывается то, что тайминги в обоих случаях были неплохо оптимизированы.
Перейдем к тестам в играх, и начнем с все той же Assassin's Creed Odyssey. Падение частоты больше чем на 20%, с 3400 до 2933 МГц, игра просто не заметила — средний FPS не изменился совершенно. А вот на DDR4-2133 игра уже выдала только 93 кадра в секунду, то есть падение производительности составило порядка 5%.
В World War Z API Vulkan показывает, что он дейсвительно ближе к железу, чем DirectX — уже на 2933 МГц мы видим падение частоты кадров с 180 до 178, а на 2133 МГц мы получаем только 169 FPS. Иными словами, максимальная потеря кадров составила 7% — не так уж и мало.
Ну и переходим к Far Cry New Dawn, и вот тут даже переход на DDR4-2933 снижает FPS на пару процентов, а на DDR4-2133 вы не досчитаетесь уже 13 кадров в секунду, что составляет 11% — достаточно внушительная потеря.
Какой можно сделать вывод? DDR4-2133 для игр брать точно не стоит, во всех протестированных играх такая память ощутимо снижает итоговый FPS. А вот DDR4-2933 показывает себя на удивление неплохо — я ожидал, что в тяжелом Assassin-е будут просадки частоты кадров, но их там не было от слова совсем. Так что Intel не зря выбрала такую частоту дефолтной для своих псевдо новых процессоров — память на ней едва ли будет узким местом в системе.
Что касается обьема ОЗУ, совсем недавно популярный зарубежный Youtube-канал Linus Tech Tips, подтвердил, то, о чем мы уже не раз говорили, объём DDR4 в 4GB почти непригоден для использования, так как после простой загрузки Windows 10 половина памяти уже была занята.
С 8 гигабайтами ОЗУ работать становиться куда приятней. Можно смело запускать 3 ролика в 4K или 27 простых вкладок. В играх потребление памяти зависит от конкретного тайтла, но 16 Гб можно смело назвать золотой серединой. C 8 Gb ОЗУ тоже жить можно, но при этом файл подкачки используется на 20% от своего объёма, так что для дополнительных фоновых процессов неплохо бы обзавестись китом памяти на 16 Gb.
Дальнейшее наращивание объёма оперативной памяти не даёт почти никакого эффекта. Этих же 16 Гб будет сполна хватать для рендера, 32 Gb ОЗУ может понадобиться либо профессионалам, либо если вы любите открывать все и сразу.
Более 32 Gb может потребоваться художникам и создателям контента, которые держат открытыми сразу несколько рабочих программ.
Ну и глобальный итог — нет особого смысла гнаться за очень быстрой памятью. Если между DDR4-2933 и DDR4-3400 разницу уже нужно искать под лупой, то уж при переходе на DDR4-4000 вам потребуется микроскоп. А ведь стоит последняя достаточно дорого, и, сэкономив на ней, вы вполне можете взять более быструю видеокарту и гарантированно получить прирост производительности в играх.
Так что на данный момент имеет смысл остановиться на 8 или лучше 16 Гб памяти с частотой около 3 ГГц, причем не нужно дополнительно ужимать тайминги, стандартного XMP-профиля вполне хватит.
Читайте также: