Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

информация о запущенном процессе

Страницы: 1 2 >
inex © (2007-08-27 12:14:00)
Добрый день, уважаемые форумчане!
Подскажите, пожалуйста, как можно узнать информацию о любом запущенном процессе. А конкретно, мне нужно знать, объем памяти, занимаемой данным процессом и загрузку ЦПУ.

Eraser (2007-08-27 16:48:00) [1]

> inex (27.08.07 16:19) [21]

можно получить практически ту же функциональность, только через wmi, т.е. документированными возможностями.

inex (2007-08-27 16:19:00) [2]

> http://www.delphisources.ru/pages/sources/system/2006_year/query_sys_info.
> html

Игорь Шевченко ссылку на данный пример давал уже.
Но все равно, спасибо!
Все-таки придется разбираться что да как.

Сергей М. (2007-08-27 16:09:00) [3]
http://www.delphisources.ru/pages/sources/system/2006_year/query_sys_info.html

inex (2007-08-27 16:03:00) [4]

> А если бы было 0,5Гб, то каким бы, по-твоему, был "критический
> объем" ?

В таком случае недостающие полтора гига компенсировал бы своп-файл. Но я бы не рисковал подымать такую "массивную" СУБД на сервере с таким к-вом RAM.

> imho, у тебя путаница в голове - ты не понимаешь разницы
> между виртуальной и физической памятью.

Просто есть реальная проблема, с которой я столкнулся, и зная, что выхода нету, кроме как изменения платформу ОС, приходится каким-то образом разделять задачи пользователей и в результате чего раскидывать БД СУБД на разные сервера. В принципе это проблема решаема и уже воплощается в жизнь.

Что-то топик резко перешел от одной проблемы к другой!
См. в начало.

Сергей М. (2007-08-27 15:49:00) [5]

> Не 0.5 Гб, а 4 Гб

А если бы было 0,5Гб, то каким бы, по-твоему, был "критический объем" ?

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

inex (2007-08-27 15:44:00) [6]

> И откуда для "твоего случая" возьмутся почти 2 Гб ОЗУ, если
> на борту его всего-то 0.5Гб, из которых в общем случае чуть
> ли не добрую половину система использует для внутренних
> нужд ?

Не 0.5 Гб, а 4 Гб!
В общем, наверное, придется использовать планировщик задач.
Просто, хотелось автоматизировать мониторинг процесса, для дальнейшего анализа нагрузки на СУБД.

Сергей М. (2007-08-27 15:30:00) [7]

> в моем случае, где-то > 1800000 Кб

Откуда такая цифирь взялась , от балды ?

И откуда для "твоего случая" возьмутся почти 2 Гб ОЗУ, если на борту его всего-то 0.5Гб, из которых в общем случае чуть ли не добрую половину система использует для внутренних нужд ?

inex (2007-08-27 15:26:00) [8]

> Вот у тебя на борту, к примеру, есть ОЗУ общей емкостью
> 512к.Вопрос на засыпку - какой ее объем, "занятый" процессом
> твоей СУБД, следует считать "критическим" ?

В таком случае я думаю все 512 Кб :-)
Ну а если серьезно, в моем случае, где-то > 1800000 Кб.

Сергей М. (2007-08-27 15:21:00) [9]

> inex (27.08.07 15:02) [10]

Вот у тебя на борту, к примеру, есть ОЗУ общей емкостью 512к.

Вопрос на засыпку - какой ее объем, "занятый" процессом твоей СУБД, следует считать "критическим" ?

inex (2007-08-27 15:18:00) [10]

> поставте СУБД на 64-х разрядную систему да и всех делов.
> зачем изобрететь велосипеды?

Ну еще есть вариант использовать Unix и др. подобные.
Но такое решение мне не подходит.

Leonid Troyanovsky (2007-08-27 15:11:00) [11]

> inex (27.08.07 15:02) [10]

> Я просто хочу написать программку, которая бы висела в системе
> и мониторила потребляемую память процесса.

Все уже украдено до нас: perfmon.exe
Только это, все равно, не наш путь.

--
Regards, LVT.

Eraser (2007-08-27 15:09:00) [12]

> inex (27.08.07 15:02) [10]

поставте СУБД на 64-х разрядную систему да и всех делов. зачем изобрететь велосипеды?

inex (2007-08-27 15:02:00) [13]

> Зачем оно может понадобиться, если ОС в любой момент вправе
> использовать опер.память по своему усмотрению, "выгоняя"
> из какого-то ее участка один процесс и тут же "вселяя" туда
> другой ?

Проблема следующего характера. Есть СУБД, процесс которой "кушает" очень много памяти. И по мере наростания сессий, потребляемая память тоже наростает. Как известно, ОС Windows для одного процесса может выделить максимум 2 Гб памяти и не больше. Поэтому, когда потребляемая память СУБД доходит к данной критичной точке, то она просто напросто виснет.
Я просто хочу написать программку, которая бы висела в системе и мониторила потребляемую память процесса. На какой-то метке она будет перегружать службу БД.

Сергей М. (2007-08-27 14:50:00) [14]

> о физической - RAM

Зачем оно может понадобиться, если ОС в любой момент вправе использовать опер.память по своему усмотрению, "выгоняя" из какого-то ее участка один процесс и тут же "вселяя" туда другой ?

inex (2007-08-27 14:44:00) [15]

> пост [3]

Спасибо конечно за примерчик, но, то ли от неполноты знаний, то ли от еще чего-то, но мне как-то сложно разобрать что там и где. Просто там много лишнего, для меня.

inex (2007-08-27 14:42:00) [16]

> Ты о какой памяти ?

о физической - RAM

Игорь Шевченко (2007-08-27 14:38:00) [17]

> Подскажите пожалуйста на явном примере

пост [3]

Сергей М. (2007-08-27 14:31:00) [18]

> Этой переменной нужно присвоить значение - используемая
> память процесса,

Ты о какой памяти ?

inex (2007-08-27 14:08:00) [19]
Конечно, большое спасибо за информацию, но
я что-то не совсем понял, как же мне все-таки узнать информацию о процессе, используя данную ф-цию:

function NtQuerySystemInformation(
SystemInformationClass:integer;
SystemInformation: pointer;
SystemInformationLength: integer;
var ReturnLength: integer): word;
external 'ntdll.dll'

Подскажите пожалуйста на явном примере. Вот есть у меня переменная типа integer. Этой переменной нужно присвоить значение - используемая память процесса, к примеру, programm.exe.

Игорь Шевченко (2007-08-27 12:26:00) [20]
http://www.schevchenko.net.ru/SRC/QuerySystemInformation_60.zip
http://www.schevchenko.net.ru/BIN/QuerySystemInformation.zip

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »