Schetchiksg.ru

Счетчик СГ
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Счетчик ошибок страниц диск что это

Счетчик ошибок страниц диск что это

Что это такое? Как понимать его показания? В справке не описано.
Это нормально, когда у программы он растет со скоростью 2-3 тыс единиц в секунду?


homm © ( 2007-05-01 14:42 ) [1]

> Что это такое? Как понимать его показания?

Да не паникуй ты так. Это количество страниц, к котрым онадобился доступ когда их не было в оперативной памяти. А если еще точнее, то количество страниц, к котрым онадобился доступ когда их не было в рабочем наборе приложения, что не значит что их не было в оперативе.


> Это нормально, когда у программы он растет со скоростью
> 2-3 тыс единиц в секунду?

Нет 🙂 Пора идти в магазин за оперативой 🙂


Eraser © ( 2007-05-01 14:42 ) [2]

> [0] DVM © (01.05.07 13:42)


> Что это такое?

это ошибка доступа к странице памяти, при её возникновении системы выгружает нужную страницу из файла подкачки в ОЗУ.

> Это нормально, когда у программы он растет со скоростью
> 2-3 тыс единиц в секунду?

не очень (хотя тут нужно смотреть конкретную ситуацию), нужно побольше ОЗУ.


homm © ( 2007-05-01 15:05 ) [3]

> Это нормально, когда у программы он растет со скоростью
> 2-3 тыс единиц в секунду?

Я счас подергал окошко оперы за края, погонял апатчь, до 5 тышь в секунду доходило. Вот же уродский оптимайзер памяти у винды 🙁 Так что пара тысячь в секунду — вполне нормально.


DVM © ( 2007-05-01 15:35 ) [4]

Я вот попытался локализовать в своей программе место, которое более всего увеличивает счетчик — оказалось это место в FastDIB. А именно:

procedure FastDIB2Bitmap(Src:TFastDIB;Dst:TBitmap);
begin
if Src.Handle<>0 then
begin
Dst.Handle:=Src.Handle;
// bitmaps can be selected for only one device context at a time
if(Src.hDC<>0)and Src.FreeDC then DeleteDC(Src.hDC);
if(Src.hPen<>0)then DeleteObject(Src.hPen);
if(Src.hFont<>0)then DeleteObject(Src.hFont);
if(Src.hBrush<>0)then DeleteObject(Src.hBrush);
Src.hDC:=0;
Src.FreeDC:=False;
Src.FreeBits:=False;
Src.FreeHandle:=False;
end;
end;

Вот такие преобразования моя программа делает до 200 в секунду.
Если я комментирую преобразование, то счетчик не растет практически.

Памяти 100% достаточно. Ее количество не влияет на этот счетчик. 2Гб ее.

ну если это не дает лишней нагрузки на CPU — можно смело забить, если нагрузку дает — исключить вызов FastDIB2Bitmap.


antonn © ( 2007-05-01 16:43 ) [6]

щас может тупой вопрос задам:)
А так — procedure FastDIB2Bitmap(Src:TFastDIB; var Dst:TBitmap);
?


DVM © ( 2007-05-01 17:13 ) [7]


> ну если это не дает лишней нагрузки на CPU

Не нагрузки не дает абсолютно. Память не растет, никакие ресурсы не уменьшаются.


> щас может тупой вопрос задам:)
> А так — procedure FastDIB2Bitmap(Src:TFastDIB; var Dst:TBitmap);
>
> ?

Все то же самое.


Eraser © ( 2007-05-01 17:28 ) [8]

> [6] antonn © (01.05.07 16:43)

в Делфи идентификатор объекта является указателем на объект )


antonn © ( 2007-05-01 18:09 ) [9]


> в Делфи идентификатор объекта является указателем на объект
> )

Я вот попытался локализовать в своей программе место, которое более всего увеличивает счетчик — оказалось это место в FastDIB.

По логике, нужно сначала всё освободить, потом присваивать Handle. Возможно, и освобождать необязательно, во всяком случае в примере Bumpmap сделано так:

procedure TBumpForm.SetThumbnail(Image:TImage; Bmp:TFastDIB);
var
Tmp: TFastDIB;
begin
Tmp:=TFastDIB.Create;
Tmp.SetSize(105,105,Bmp.Bpp);
if Tmp.Bpp=8 then
begin
Tmp.Colors^:=Bmp.Colors^;
Tmp.UpdateColors;
end;

Bilinear(Bmp,Tmp);
Tmp.FreeHandle:=False;
Image.Picture.Bitmap.Handle:=Tmp.Handle;
Tmp.Free;
Image.Refresh;
end;

А вообще, откуда надобность выполнять подобное преобразование 200 раз/c? Может лучше выкинуть TBitmap и выполнять все операции с TFastDIB? А то мне сейчас лень смотреть, но подозреваю, что в TBitmap.SetHandle куда больше действий, чем просто присвоение переменной.

Ещё, имейте в виду, что FastGate — это не оригинальный FastLIB. Автор этого модуля уже допускал ляпы при «улучшении» библиотеки, так что аккуратнее с ним (хотя, строго говоря, и «оригинал» не безгрешен).


DVM © ( 2007-05-01 22:03 ) [11]


> А вообще, откуда надобность выполнять подобное преобразование
> 200 раз/c?

Да есть вот задачи. Видеонаблюдение.


> Может лучше выкинуть TBitmap и выполнять все операции с
> TFastDIB?

Так и планирую сделать, но есть свои грабли и очень много вносить изменений. В принципе FastDIB тут прикручен из-за фантастически быстрой SetSize.


> TBitmap.SetHandle куда больше действий, чем просто присвоение
> переменной.

Да, там намного больше действий.


> Sapersky

Не подскажите, как правильно скопировать один TFastDIB в другой. Не Assign(), а именно копирование? У меня вот какая штука:

Во вторичном потоке происходит декодирование JPEG в TFastDIB. Далее этот FastDIB с сообщением высылается в основной поток и там преобразуется в TBitmap, который и отрисовывается при необходимости в основном потоке по WM_PAINT. Так сделано сейчас. Так вот получается, что и основной поток и вторичный на деле же работают с одним и тем же хэндлом одного и того же битмапа по сути. Ведь FastDIB2Bitmap просто присваивает хэндл. И пока первичный поток отрисовывает его на окне вторичный ведь может и поменять его содержимое. Или я неправ? Так можно делать или надо полностью копироваить битмап в основной поток и там работать с ним?

Читайте так же:
Схема устройства счетчика гейгера


homm © ( 2007-05-01 22:06 ) [12]

Хм, а я кажеться понял почему так много ошибок доступа в этом месте. Потому что по Dst.Handle:=Src.Handle; Dst фактически заново создаеться, под новый битмап выделяеться память. А менеджер памяти в виндовсе имеет такое замечательное свойство, не выделять память физически, а лишь помечать страницы как зарезервированые. А вот когда уже на новый хэндл уже копируеться изображение со старого, идет непосредственное обращение к страницам, и они выделяются физически (в ОП), а счетчик ошибок доступа мотает. Так что эта строчка имхо — большая дыра в производительности. Попробуй как минимум создавать TBitmap как DIB, как максимум, здесь вобще нужно логику программы переделывать.


homm © ( 2007-05-01 22:11 ) [13]

> Так вот получается, что и основной поток и вторичный на
> деле же работают с одним и тем же хэндлом одного и того
> же битмапа по сути.

Скорее всего нет. Как я понимаю невозможно преобразовать DDB в DIB не выделив под него второй хэндл.


DVM © ( 2007-05-01 22:21 ) [14]


> Потому что по Dst.Handle:=Src.Handle; Dst фактически заново
> создаеться, под новый битмап выделяеться память

Да, получается, что так.


> Так что эта строчка имхо — большая дыра в производительности.

Может быть, но это далеко не самая тяжелая операция. Декодирование из JPEG во вторичных потоках занимает в тысячи раз больше времени.


> как максимум, здесь вобще нужно логику программы переделывать.

Я вот попробовал переделать на TFastDIB в основном потоке — проблема с ошибками страницы исчезла.

Возникла другая проблема — как мне правильно передать с сообщением переменную типа TFastDIB из вторичного потока в первичный с сообщением и присвоить полченное в основном потоке значение переменной в первичном потоке. Просто присваиванием очевидно нельзя — возникают сразу утечки GDI ресурсов (вот здесь отличие от TBITMAP).


Sapersky ( 2007-05-02 00:38 ) [16]

Не подскажите, как правильно скопировать один TFastDIB в другой. Не Assign(), а именно копирование?

Dst.MakeCopy(Src, True); // делается SetSize и Move
Или можно (при UseGDI = True) установить размер Dst = Src, потом
Src.Draw(Dst.hDC, 0, 0); // фактически BitBlt
удобно тем, что конвертирует битмапы разных форматов, хотя, как правило, не очень качественно. Впрочем, для этого есть FConvert.pas.

И пока первичный поток отрисовывает его на окне вторичный ведь может и поменять его содержимое. Так можно делать или надо полностью копироваить битмап в основной поток и там работать с ним?

Если вторичный поток не изменяет размер битмапа, т.е. не портит указатель/Handle, то, наверное, можно его спокойно рисовать, в крайнем случае нарисуется половина старого, половина нового. Хотя сам не пробовал, не знаю, как функции GDI отнесутся к тому, что кто-то будет писать в используемую ими область памяти. Можно на всякий случай прицепить к битмапу крит. секцию.
Если изменяет — тогда однозначно нужна или синхронизация, или копирование, или и то, и другое.

Просто присваиванием очевидно нельзя — возникают сразу утечки GDI ресурсов (вот здесь отличие от TBITMAP).
Что такое «присваивание»?
Если Assign — возможно, «аффтар» FastGate с ним напортачил в новой версии, пытаясь добиться того же поведения, что и у TBitmap. В оригинале это поведение довольно специфическое — битмап-источник уничтожается.
В общем, лучше «присваивание» делать как Dst := Src с соответствующей синхронизацией или MakeCopy.


Игорь Шевченко © ( 2007-05-02 10:29 ) [17]


> Вот же уродский оптимайзер памяти у винды

Слону, сам понимаешь, пофиг.


DVM © ( 2007-05-02 13:00 ) [18]


> Sapersky (02.05.07 00:38) [16]

Большое спасибо. Метод TFastDib.MakeCopy() действительно то что нужно.

Счетчики ошибок страницы не растут. Утечек тоже нет. Как обстоят дела с производительностью такого решения выясняю.

Счетчик ошибок страниц диск что это

Этот раздел описывает некоторые счетчики Performance Monitor, связанные с мониторингом памяти:

♦ Buffer Cache Hit Ratio (% использования выделенной памяти), здесь Object — Memory (Память);

♦ Pages/sec (Обмен страниц 8 сек.), здесь Object — Memory;

♦ Page Faults/sec (Ошибок страницы/сек.), здесь Object — Memory.

В этом разделе также описывается одна команда и два представления, связанные с мониторингом памяти:

Счетчик Buffer Cache Hit Ratio отображает процент страниц, которые не требуется читать с диска. Чем выше это отношение, тем реже система должна обращаться к жесткому диску для чтения данных, при этом улучшается общая производительность. Обратите внимание, что не существует правильного значения этого счетчика, потому что оно зависит от приложения.

Счетчик Pages/sec отображает объем обмена страниц (т. е. количество страниц, записанных на диск или считанных с диска в секунду). Этот счетчик является важным индикатором наличия ошибок, которые приводят к проблемам производительности. Если значение этого счетчика слишком велико, вы должны принять решение о дополнительной физической памяти.

Счетчик Page Faults/sec отображает среднее количество ошибок страниц в секунду. Этот счетчик включает как программные ошибки, так и ошибки диска. Ошибки страниц появляются, когда системный процесс ссылается на виртуальную страницу памяти, которая в этот момент не находится в рабочей области физической памяти. Если запрашиваемая страница находится в списке простаивающей памяти или страница в настоящий момент разделяется другими процессами, то генерируется ошибка программной страницы, и ссылка на память разрешается без физического обращения к диску. Однако если страница, на которую осуществляется ссылка, находится в файле страниц, то генерируется ошибка страницы диска, и данные должны быть загружены с диска.

Читайте так же:
Как установить счетчик для полива

Команда dbcc memorystatus предоставляет мгновенный снимок текущего состояния памяти Database Engine. Вывод этой команды полезен в процессе исправления ошибок, которые связаны с использованием памяти Database Engine или со специфическими ошибками памяти (многие из которых автоматически отправляют этот вывод в протокол ошибок).

Представление sys.dm_os_memory_cierks возвращает набор всех служб памяти, которые являются активными в текущем экземпляре. Вы можете использовать это представление для получения распределения памяти для различных типов памяти.

Представление sys.dm_os_memory_objects возвращает объекты памяти, которые в настоящий момент распределены системой базы данных. Это представление динамического управления в первую очередь служит для анализа использования памяти и для анализа возможного недостатка памяти, как показано в примере 21.2.

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

На какие сегменты влияет a copy-on-write?

Мое понимание copy-on-write заключается в том, что «у каждого есть одна общая копия одних и тех же данных, пока они не будут записаны, а затем сделана копия».

  1. Является ли общая копия одних и тех же данных состоящей из кучи и сегмента bss или только кучи?
  2. Какие сегменты памяти будут совместно использоваться, и зависит ли это от OS?

linuxmemory-managementoperating-systemcopy-on-write

2 ответа

  • Что такое copy-on-write?

Я хотел бы знать, что такое copy-on-write и для чего он используется? Термин массив copy-on-write несколько раз упоминается в учебниках Sun JDK, но я не понял, что он означает.

Я ищу .NET copy-on-write коллекций для использования в C# программах, таких как список, Словарь и т. д. Какие коллекции обладают этим свойством?

OS может установить любую политику «copy on write», какую пожелает, но, как правило, все они делают одно и то же (т. Е. То, что имеет наибольший смысл).

В общем, для системы, подобной POSIX (linux, BSD, OSX), есть четыре области (то, что вы называли сегментами), представляющие интерес: data (куда идет int x = 1; ), bss (куда идет int y ), sbrk (это heap/malloc), и stack

Когда fork будет сделано, OS настроит новую карту страниц для дочернего элемента, который совместно использует все страницы родителя. Затем в картах страниц родителя и ребенка все страницы помечаются только для чтения.

Каждая карта страниц также имеет счетчик ссылок, который указывает, сколько процессов совместно используют страницу. До fork количество ссылок будет равно 1, а после-2.

Теперь, когда любой из процессов попытается записать на страницу R/O, он получит ошибку страницы. OS увидит, что это для «копирования при записи», создаст личную страницу для процесса, скопирует данные из общего доступа, пометит страницу как доступную для записи для этого процесса и возобновит ее.

Это также приведет к снижению количества рефкоутов. Если значение refcount теперь [снова] 1, OS пометит страницу в другом процессе как доступную для записи и не доступную для общего доступа [это устраняет ошибку второй страницы в другом процессе-ускорение только потому, что в этот момент OS знает, что другой процесс должен быть свободен для записи без изменений снова]. Это ускорение может зависеть от OS.

На самом деле, раздел bss получает еще более особое отношение. В начальном сопоставлении страниц для него все страницы сопоставляются с одной страницей, содержащей все нули (она же «нулевая страница»). Отображение помечено R/O., поэтому область bss может иметь размер в гигабайтах, и она будет занимать только одну физическую страницу. Эта единственная, специальная, нулевая страница является общей для всех bss разделов всех процессов, независимо от того, имеют ли они какое- либо отношение друг к другу вообще.

Таким образом, процесс может читать с любой страницы в этой области и получает то, что он ожидает: ноль. Это происходит только тогда, когда процесс пытается записать на такую страницу, срабатывает тот же механизм копирования при записи, процесс получает личную страницу, сопоставление корректируется, и процесс возобновляется. Теперь он может свободно писать на страницу так, как считает нужным.

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

Когда exec syscall выполняется [на дочернем устройстве], kernel должен отменить большую часть сопоставления, выполненного во время fork [отбрасывания пересчетов], Освобождения сопоставления дочернего устройства и т. Д. И восстановления исходной защиты родительской страницы (т. Е. Он больше не будет делиться своими страницами, если не сделает еще один fork )

Хотя это не является частью вашего первоначального вопроса, есть связанные действия, которые могут представлять интерес, такие как загрузка по требованию [страниц] и связывание по требованию [символов] после exec syscall.

Когда процесс выполняет exec , kernel выполняет описанную выше очистку и считывает небольшую часть исполняемого файла, чтобы определить его формат объекта. Доминирующим форматом является ELF, но может использоваться любой формат, который понимает kernel (например, OSX может использовать ELF [IIRC], но у него также есть другие).

Читайте так же:
Что gsm модем счетчику меркурий

Для ELF исполняемый файл имеет специальный раздел, который дает полный путь FS к тому, что известно как «интерпретатор ELF», который является общей библиотекой и обычно является /lib64/ld.linux.so .

kernel, используя внутреннюю форму mmap , сопоставит это с пространством приложения и настроит сопоставление для самого исполняемого файла. Большинство вещей помечены как R/O страниц и «not present».

Прежде чем мы пойдем дальше, нам нужно поговорить о «backing store» для страницы. То есть, если происходит ошибка страницы, и нам нужно загрузить страницу с диска, откуда она взялась. Для heap/malloc, это, как правило, диск подкачки [он же диск подкачки].

В разделе linux обычно используется раздел типа «linux swap», который был добавлен при установке системы. Когда записывается страница, которая должна быть сброшена на диск, чтобы освободить некоторую физическую память, она записывается туда. Обратите внимание, что алгоритм совместного использования страниц в первом разделе по-прежнему применяется.

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

Таким образом, kernel устанавливает счетчик программ приложения так, чтобы он указывал на начальное местоположение интерпретатора ELF, и передает ему управление.

Переводчик ELF занимается своими делами. Каждый раз, когда он пытается выполнить часть себя [страница «code»], которая сопоставлена , но не загружена, возникает ошибка страницы, и она загружает эту страницу из резервного хранилища (например, файл интерпретатора ELF) и изменяет сопоставление на R/O, но присутствует .

Это происходит для интерпретатора ELF, общих библиотек и самого исполняемого файла.

Интерпретатор ELF теперь будет использовать mmap для отображения libc в пространство приложения [опять же, при условии загрузки по требованию]. Если интерпретатору ELF приходится изменять кодовую страницу для перемещения символа [или пытается записать в любой файл, содержащий файл в качестве резервного хранилища, например страницу data ], возникает ошибка защиты, kernel изменяет резервное хранилище для страницы из файла на диске на страницу на диске подкачки, настраивает защиту и возобновляет работу приложения.

kernel также должен обрабатывать случай, когда интерпретатор ELF (например) пытается написать на [скажем] страницу data , которая еще не была загружена (т. е. сначала он должен загрузить его, а затем сменить резервное хранилище на диск подкачки)

Затем интерпретатор ELF использует части libc , чтобы помочь ему выполнить начальные действия по связыванию. Он перемещает минимум, необходимый для выполнения своей работы.

Однако интерпретатор ELF не перемещает все символы для большинства других общих библиотек. Он просмотрит исполняемый файл и, снова используя mmap , создаст сопоставление для общих библиотек, необходимых исполняемому файлу (т. е. что вы видите, когда делаете ldd executable ).

Эти сопоставления с разделяемыми библиотеками и исполняемыми файлами можно рассматривать как «segments».

В каждой общей библиотеке есть таблица переходов символов, которая указывает на интерпретатор. Но интерпретатор ELF вносит минимальные изменения.

[ Примечание: это свободное объяснение] Только тогда, когда приложение пытается вызвать запись перехода данной функции [это то, что GOT и др. вещи, которые вы, возможно, видели], происходит перемещение. Запись перехода передает управление интерпретатору, который находит реальный адрес символа и настраивает GOT таким образом, чтобы он теперь указывал непосредственно на конечный адрес символа и повторял вызов, который теперь вызовет реальную функцию. При последующем вызове той же заданной функции она теперь идет напрямую.

Это называется «on demand linking».

Побочным продуктом всей этой деятельности mmap является классический системный вызов sbrk , который практически бесполезен. Вскоре он столкнется с одним из отображений памяти общей библиотеки.

Итак, modern libc не использует его. Когда malloc требуется больше памяти от OS, он запрашивает больше памяти от анонимного mmap и отслеживает, какие выделения принадлежат какому отображению mmap . (т. Е. Если освободилось достаточно памяти, чтобы охватить все отображение, free может выполнить munmap ).

Итак, подводя итог, у нас есть «copy on write», «on demand loading», and «on demand linking» все происходит в одно и то же время. Это кажется сложным, но заставляет fork и exec работать быстро и плавно. Это добавляет некоторую сложность, но дополнительные накладные расходы выполняются только при необходимости («по требованию»).

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

  • Copy-on-write поддержка в STL

Я только что читал статью Википедии о Copy-on-write (любопытно, есть ли какие-либо файловые системы, которые поддерживают его), и был удивлен следующим отрывком: COW также используется вне kernel, в библиотечном, прикладном и системном коде. Например, класс string, предоставляемый стандартной.

Можно ли добавить программное обеспечение copy-on-write для многопоточных приложений в Java? Под этим я подразумеваю потоки, имеющие ссылку на один и тот же объект, но когда один поток пытается изменить его, объект, на который он указывает, копируется, и ссылка настраивается так, чтобы указывать.

Чтобы лучше понять, вам следует исключить этот термин из своего словарного запаса. Большинство систем работают на страницах, а не на сегментах. В 64-bit сегменты Intel наконец-то ушли.

Читайте так же:
Уголок по установке счетчиков

Вы должны спросить, «What pages are affected in copy on write.»

Это будут страницы, доступные для записи и совместно используемые несколькими процессами, когда один процесс записывает на них.

Это может произойти после fork. Одним из способов реализации разветвления является создание полной копии адресного пространства родительского процесса. Тем не менее, это может потребовать больших усилий, особенно потому, что большую часть времени вы выполняете exec в ребенке сразу после fork.

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

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

Похожие вопросы:

основан ли QImage на QSharedData ? Следует ли Qimage за pimpl или copy on write ? например, будет ли копирование (через copy con или присваивание) Qimage создавать глубокую копию пикселей ?

Использование Python 2.5+, UNIX: У меня есть программа, которая имитирует функциональность каталога copy-on-write, жестко связывая все записи. В настоящее время весь базовый код, к некоторым из.

Скажем, у меня есть процесс в Linux, из которого я fork() другой идентичный процесс. После fork ing, когда исходный процесс начнет запись в память, механизм Linux copy-on-write даст процессу.

Я хотел бы знать, что такое copy-on-write и для чего он используется? Термин массив copy-on-write несколько раз упоминается в учебниках Sun JDK, но я не понял, что он означает.

Я ищу .NET copy-on-write коллекций для использования в C# программах, таких как список, Словарь и т. д. Какие коллекции обладают этим свойством?

Я только что читал статью Википедии о Copy-on-write (любопытно, есть ли какие-либо файловые системы, которые поддерживают его), и был удивлен следующим отрывком: COW также используется вне kernel, в.

Можно ли добавить программное обеспечение copy-on-write для многопоточных приложений в Java? Под этим я подразумеваю потоки, имеющие ссылку на один и тот же объект, но когда один поток пытается.

Поскольку я постоянно записываю данные в redis, память, используемая copy-on-write, продолжает увеличиваться. Даже если я пишу свою программу в спящий режим достаточно долго, чтобы redis смог.

У нас есть некоторый код , который опирается на широкое использование fork . Мы начали сталкиваться с проблемами производительности, и одна из наших гипотез заключается в том, что мы действительно.

Я читал о реализации copy-on-write для массива в Swift здесь . Массивы, как и все коллекции переменных размеров в стандартной библиотеке, используют оптимизацию copy-on-write. Несколько копий.

О чем говорят ошибки отсутствия страницы в памяти

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

Алгоритмы с квантованием.

Каждому потоку предоставляется квант времени, в течение которого поток может выполняться на процессоре. По истечении кванта операционная система переключает процессор на следующий поток в очереди. Квант обычно равен целому числу интервалов системного таймера1.

Алгоритмы с приоритетами.

Каждому потоку назначается приоритет (priority) – целое число, обозначающее степень привилегированности потока. Операционная система при наличии нескольких готовых к выполнению потоков выбирает из них поток с наибольшим приоритетом.

В Windows реализован смешанный алгоритм планирования – вытесняющий, на основе квантования и приоритетов.

  1. Тип многозадачности для приложения DOS
  2. Гарантии обслуживания
  3. Планирование процессов переднего плана
  4. Назначение файла подкачки
  5. Процессы Р1, Р2, Р3 выделяют 100, 20, 80 Мб памяти. В системе 128Мб ОП. Каков размер занятой памяти в файле подкачки. Какой размер файла подкачки.
  1. Что такое «страничная ошибка»?

Прерывание 14 —Страничная ошибка(#PF): Intel386 …

Генерируется, если страничный механизм активизирован (CR0.PG = 1) и при трансляции линейного адреса в физический возникает одна из следующих ситуаций:

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

Обработчик страничной ошибки получает информацию о ее причине из двух источников: кода ошибки, помещаемого в стек, и содержимого регистра CR2, который содержит линейный адрес, вызвавший ошибку. Код страничной ошибки имеет специальный формат (рис. 3.7.).

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

Если страничная ошибка была вызвана в связи с нарушением привилегий страничной защиты, то бит доступа (A) в соответствующем элементе каталога страниц устанавливается. Поведение бита доступа в соответствующем элементе таблиц страниц для этого случая не регламентируется в процессорах Intel и может быть разным в различных моделях.

  1. Высокая интенсивность ошибок страниц говорит о:
Читайте так же:
Как счетчик для dle

— ненадежности оперативной памяти

Графа «Ошибок отсутствия страницы в памяти/сек.»

В графе «Ошибок отсутствия страницы в памяти/сек.» (Hard Faults/sec) указано среднее за последнюю минуту количество ошибок отсутствия страницы в памяти в секунду. Если процесс пытается использовать больше физической памяти, чем доступно в данный момент времени, система записывает часть данных из памяти на диск — в файл подкачки. Последующее обращение к данным, сохраненным на диск, и называется ошибкой отсутствия страницы в памяти.

О чем говорят ошибки отсутствия страницы в памяти

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

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

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

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

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

  1. Как формируется приоритет потока в Windows

В ОС Windows реализовано вытесняющее приоритетное планирование, когда каждому потоку присваивается определенное числовое значение — приоритет, в соответствии с которым ему выделяется процессор. Потоки с одинаковыми приоритетами планируются согласно алгоритму Round Robin (карусель). Важным достоинством системы является возможность вытеснения потоков, работающих в режиме ядра — код исполнительной системы полностью реентерабелен. Не вытесняются лишь потоки, удерживающие спин-блокировку (см. Синхронизация потоков ). Поэтому спин-блокировки используются с большой осторожностью и устанавливаются на минимальное время.

В системе предусмотрено 32 уровня приоритетов. Шестнадцать значений приоритетов (16-31) соответствуют группе приоритетов реального времени, пятнадцать значений (1-15) предназначены для обычных потоков, и значение 0 зарезервировано для системного потока обнуления страниц (см. рис. 6.2).

Рис. 6.2.Приоритеты потоков

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

  • реального времени ( REALTIME_PRIORITY_CLASS ) — 24
  • высокий ( HIGH_PRIORITY_CLASS ) — 13
  • выше нормы ( ABOVE_NORMAL_PRIORITY_CLASS ) 10
  • нормальный ( NORMAL_PRIORITY_CLASS ) — 8
  • ниже нормы ( BELOW_NORMAL_PRIORITY_CLASS ) — 6
  • и неработающий ( IDLE_PRIORITY_CLASS ) 4

Относительный приоритет потока устанавливается аналогичными параметрами функции SetThreadPriority:

Совокупность из шести классов приоритетов процессов и семи классов приоритетов потоков образует 42 возможные комбинации и позволяет сформировать так называемый базовый приоритет потока

Базовый приоритет процесса и первичного потока по умолчанию равен значению из середины диапазонов приоритетов процессов (24, 13, 10, 8, 6 или 4). Смена приоритета процесса влечет за собой смену приоритетов всех его потоков, при этом их относительные приоритеты остаются без изменений.

Приоритеты с 16 по 31 в действительности приоритетами реального времени не являются, поскольку в рамках поддержки мягкого реального времени, которая реализована в ОС Windows, никаких гарантий относительно сроков выполнения потоков не дается. Это просто более высокие приоритеты, которые зарезервированы для системных потоков и тех потоков, которым такой приоритет дает пользователь с административными правами. Тем не менее, наличие приоритетов реального времени, а также вытесняемость кода ядра, локализация страниц памяти (см. Функционирование менеджера памяти ) и ряд дополнительных возможностей — все это позволяет выполнять в среде ОС Windows приложения мягкого реального времени, например, мультимедийные. Системный поток с нулевым приоритетом занимается обнулением страниц памяти. Обычные пользовательские потоки могут иметь приоритеты от 1 до 15.

Статьи к прочтению:
  • Оделирование в сапр. пакет nastran.
  • Одели случайных и хаотических блужданий.

Пусть говорят — «Вы мне не верили, а я умерла»Выпуск от 11.09.217

Похожие статьи:

Одним из методов борьбы с фрагментацией является перемещение всех занятых участков в сторону старших либо в сторону младших адресов так, чтобы все…

На рис. 10 показана схема страничного распределения памяти. Виртуальное адресное пространство каждого процесса делится на части одинакового,…

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector