ivsmir ..:COBECTb:.. GooddyС этом ясно - 2Gb.
А в каком каталоге он находится?для 64-битной операционки?
пацталом Да уж. А у SAP например для 64-битного HP-UX (другой уже наверное сложно найти) требования к swap - не менее 20 GB.

Данный вопрос автора топика имеет смысл только при уточнении ОС. Со swap все работают по-разному и ограничения соответственно разные.



Вы себе представляете какая должна быть скорость обмена с диском, что бы обеспечить
адекватную скорость работы ОС с 20 Гб используемого свопа.

При нынешней стоимости ОЗУ большой swap обычно от жадности подкрепленной определенной долей ламерства, или наоборот от ламерства в сочетании с жадностью.

з.ы. Жадный платит дважды, а лох по жизни.

Scott Tiger вариант
Вы себе представляете какая должна быть скорость обмена с диском, что бы обеспечить
адекватную скорость работы ОС с 20 Гб используемого свопа.

При нынешней стоимости ОЗУ большой swap обычно от жадности подкрепленной определенной долей ламерства, или наоборот от ламерства в сочетании с жадностью.

з.ы. Жадный платит дважды, а лох по жизни.

А зачем загонять систему в ситуацию, когда 20Гб страниц надо засвопить? Требования SAP (и любых других вендоров) говорят о том, что их ПО аллокирует 20Гб памяти таким образом, что для неё необходимо резервировать место в свопе.

Может САП и аллокирует, не знал, я подозреваю, что это рекомендация 10 летней давности.
С того момента вендор никак не пересматривал ни сам софт ни окружение в котором он же
его рекомендует запускать.

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

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

ИМХО, ничего полезного в большом свопе я не вижу.

2 Scott Tiger вы же сами
Scott Tiger вариантМожет САП и аллокирует, не знал, я подозреваю, что это рекомендация 10 летней давности. С того момента вендор никак не пересматривал ни сам софт ни окружение в котором он же его рекомендует запускать.

Глупости говоришь. Место в свопе аллокируется для того, чтобы была возможность туда гарантированно сбросить менее всего нужные страницы, если такая потребность возникнет .


Мне тяжело представить задачу для которой возникает потребность в 20 Гб свопа.

Обратите внимание на слово возникает ,
это не значит что происходит постоянно, а совсем наоборот.


Scott Tiger
вариантЕсли программа( ее память) большая и ее активность нужна не часто, ее дешевле запустить заново , чтобы она вкачала все неоходимые данные из своих файлов чем поднимать ее из свопа.

Порвало :) А если у неё 1 конфиг в 2 строчки и несколько гигабайт математических данных, которые расчитываются несколько суток из этих 2 строчек? Лучше просто не загонять её в своп.


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

А что тогда лучше(можно) заганять в своп( пожертвовать).
В нынешние времена скорость получения точной инфрмации ( результатов расчетов) гораздо
дороже лишней планки ОЗУ.

Если жертвовать нечем, то зачем аж 20 Гб свопа.

Можете привести пример задачи с гигом данных и 2-мя строками параметров
и расчетом около суток.


Scott Tiger
вариантСвоп очень сильно влияет на времени выполнения операции, на нынешних системах от случая к случаю оно может отличаться в десятки или даже сотни раз.

Разумеется - операции с диском на несколько порядков медленне операций с памятью, и собственно получение данных страницы памяти займёт ничтожное время по сравнению с page-in-ом (хотя там могут быть медленными не только дисковые операции: например, сильно фрагментированная память при использовании и пейджинге страниц разного размера может вызвать перемещение мелких страниц для расчистки места для одной большой страницы, а эта операция может занимать значительное время и влиять на производительность процессов, чьи страницы перемещаются - особенно на больших NUMA-машинах).


То что Вы описали действительно только для систем выполняющих множество мелких
разноплановых задачек, или для firebird classic.

Все уважающие системы, использующие много ОЗУ, предпочитают использовать DirectIO
что бы не получать оверхед на копирование участков памяти через процессоры.
А также оверхед на рефрагментацию памяти под дисковым кешем.
А также имеют собственные(внутрениие) манагеры памяти и запрашивают память у ОС большими порциями.


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


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


Scott Tiger
Ну будет он у тебя отображаться на физическую же память - чего хорошего?

Сути этого вопроса я не понял.

VoDA вариантМне тяжело представить задачу для которой возникает потребность в 20 Гб свопа.

Обратите внимание на слово возникает , это не значит что происходит постоянно, а совсем наоборот.То, что кому то трудно представить такую задачу не значит, что их не существует.


Еще раз , Обратите внимание на слово возникает.

VoDA
вариантМожете привести пример задачи с гигом данных и 2-мя строками параметров
и расчетом около суток.Простейший:
И сколько будет задействовано памяти / времени для рассчетов зависит от размера данных, ОЗУ, swap, ОС и реализации СУБД.

В контексте темы пример не катит.
СУБД используют пространство временного хранения(TEMP) в таких случаях.
Или говорите какую СУБД вы имеете ввиду.
СУБД гораздо лучше знает, что где и как искать на диске в своем TEMP TBS чем
ОС для некоего нетипизированного процесса в свопе.
По сему использование TEMP всегда будет производительнее в случае рассмотрения
TEMP vs SWAP в контексте любой СУБД поддерживающей TEMP TBS.
Недосток СУБД в виде отсутствия TEMP TBS не нужно рассматривать как достоинство SWAP.


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

Не ел и нехочу.
Вы хотите сказать что существует приложение и его окружене (ОС и железо) где
приложение которое свопится будет работать быстрее чем без свопа.
пример в студию.

Большой своп может быть полезен только как затыкание дыры на уже работающей системе( что бы хоть как нибудь дышало).
Проектировать систему с учетом использования большого обьема свопа ИМХО недальневидно.

Scott Tiger вариант
Мне тяжело представить задачу для которой возникает потребность в 20 Гб свопа.

Обратите внимание на слово возникает ,
это не значит что происходит постоянно, а совсем наоборот.


Представь теперь любую другую задачу, которой нужно, допустим, 30 Гб, а у нас всего 40Гб физической, 20 из которых заняты означенным SAPом. Половину SAP-а придётся вытеснить в своп, значит, уже нужно иметь 10Гб свопа.

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


Попоточный/попроцессный своппинг? А зачем до такого доводить? У всех уже давно страничная организация памяти, и, соответственно, постраничный обмен между памятью и backing store в нормальном режиме работы.

вариант
А что тогда лучше(можно) заганять в своп( пожертвовать).
В нынешние времена скорость получения точной инфрмации ( результатов расчетов) гораздо
дороже лишней планки ОЗУ.


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



Вы наверное профи флеймер :).
Перечитайте обсуждение .
При чем тут Попоточный/попроцессный своппинг?
Что такое страничный пайджинг я хорошо знаю.

Scott Tiger
вариант
Можете привести пример задачи с гигом данных и 2-мя строками параметров
и расчетом около суток.


Математическое моделирование физических процессов.


Методом конечных элементов я считал в ВУЗе на листике за ленту с граничными условиями в 2 строки без всяких компов.
Если есть изменения геометрии материалов, стыки материалов ( пайка, сварка... и тд),
наличие нескольких сред( жидкость, газ) вы в пару сотен килобайт невложитесь.
Хотя их можно записать и в одну строку :)

Scott Tiger
вариант Scott Tiger
вариантСвоп очень сильно влияет на времени выполнения операции, на нынешних системах от случая к случаю оно может отличаться в десятки или даже сотни раз.

Разумеется - операции с диском на несколько порядков медленне операций с памятью, и собственно получение данных страницы памяти займёт ничтожное время по сравнению с page-in-ом (хотя там могут быть медленными не только дисковые операции: например, сильно фрагментированная память при использовании и пейджинге страниц разного размера может вызвать перемещение мелких страниц для расчистки места для одной большой страницы, а эта операция может занимать значительное время и влиять на производительность процессов, чьи страницы перемещаются - особенно на больших NUMA-машинах).


То что Вы описали действительно только для систем выполняющих множество мелких
разноплановых задачек, или для firebird classic.

Все уважающие системы, использующие много ОЗУ, предпочитают использовать DirectIO
что бы не получать оверхед на копирование участков памяти через процессоры.
А также оверхед на рефрагментацию памяти под дисковым кешем.
А также имеют собственные(внутрениие) манагеры памяти и запрашивают память у ОС большими порциями.


При чём здесь DirectIO? Я вообще здесь не касаюсь проблем дискового ввода-вывода приложением. Описанный мной случай наблюдался с, видимо, совершенно не уважающей себя :) СУБД Oracle, которая, помимо своего менеджера памяти и невытесняемой в своп ISM, использует и вытесняемую память для анонимных аллокаций памяти серверными процессами, равно как и ОС загружает разделяемый код бинарников и библиотек в точно такую же вытесняемую память. При недостатке памяти вывалиться в своп как раз и могут (при определённых условиях) страницы с кодом или PGA.


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


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


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


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

вариант Scott Tiger
Ну будет он у тебя отображаться на физическую же память - чего хорошего?

Сути этого вопроса я не понял.

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



Приведите пример из любой ОС ( со ссылкой да доку) выделения свопа
в оперативной (физической) памяти ( не на RAM диске ) и продолжим разговор
о непонимании механизмов работы виртуальной памяти , и как это выглядит.

Scott Tiger

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


Резервирование места в свопе происходит безотносительно чьего бы то ни было подхода :)


Согласитесь, что- бы решать проблемы с производительностью хоть какой то подход нужен.
При падении производительности в 10 -ки раз ускорение к подходу обычно придает руководство.
:)

Мне лично проще заранее обосновать дополнительные обьем ОЗУ или
пнуть програмеров с вендорами, когда система только начинает лезть в своп,
чем самому испытывать ускорение к подходу.

Scott Tiger
вариант
Приведите пример из любой ОС ( со ссылкой да доку) выделения свопа
в оперативной (физической) памяти ( не на RAM диске ) и продолжим разговор
о непонимании механизмов работы виртуальной памяти , и как это выглядит.

Solaris устроит? Общедоступную ссылку поищу завтра, а так - в книге "Solaris Internals" тема раскрыта достаточно подробно. Впрочем, думаю, во всех юниксах сейчас своп - виртуальный.

Вполне.

Scott Tiger вариант
Scott Tiger
вариант
Приведите пример из любой ОС ( со ссылкой да доку) выделения свопа
в оперативной (физической) памяти ( не на RAM диске ) и продолжим разговор
о непонимании механизмов работы виртуальной памяти , и как это выглядит.

Solaris устроит? Общедоступную ссылку поищу завтра, а так - в книге "Solaris Internals" тема раскрыта достаточно подробно. Впрочем, думаю, во всех юниксах сейчас своп - виртуальный.

Вполне.

Как оказалось, означенную книгу (1-е издание) можно легально почитать в онлайне. http://books.google.com/books?id=r_cecYD4AKkC&pg=PA236&lpg=PA236&source=web&ots=oBofl3wFCQ&sig=nsNygViC_2dGPBbTXTHmXLtr2uA

Книга написана во времена 7-й версии, т.ч. некоторые вещи существенно изменились (например, кэш ФС). Но прочитать стоит в любом случае.

Ненашел ничего про выделение свопа в пямяти кроме области swap reservation,
бегло ознакомившись с понятием swapfs layer и понял что swap reservation ( который находится
в оперативной памяти ) никаких страниц не хранит , это структура
позволяющая мапить адреса физической(оперативной) памяти со смещениями(адресами) в файле
свопа, а также быстро вычислять возможность сброса страниц в своп.
Фактически это управляющая структура.

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

Scott Tiger
вариант Scott Tiger
Ну будет он у тебя отображаться на физическую же память - чего хорошего?

Сути этого вопроса я не понял.

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


Прошу прокомментировать, что значит размещать своп в физической(оперативной) памяти?


в качестве з.ы.

Очень интересная цитата из описания swapfs layer , которая раскрывает предисторию на требования консалтеров, о которых говорил Денис Журавлев:
автор
Traditional UNIX implementations need a page-sized unit of swap space for every page-sized unit of writable virtual memory. For example, a malloc request of 8 Mbytes on a traditional UNIX system would require us to reserve 8 Mbytes of swap disk space, even if that space was never used. This requirement led to the old rule of swap space = 2 x memory size—the rough assumption was that processes would, on average, have a virtual size about twice that of the physical pages they consumed. The swapfs layer allows Solaris to be much more conservative; you only need swap space for the amount of virtual memory that is larger than the pageable physical memory available in the machine.

Scott Tiger http://books.google.com/books?id=r_cecYD4AKkC&pg=PA236&lpg=PA236&source=web&ots=oBofl3wFCQ&sig=nsNygViC_2dGPBbTXTHmXLtr2uA#PPA158,M1

На 158 странице всё хорошо написано. В частности:


The swapfs file system includes all available pageable memory as virtual swap
space in addition to the physical swap space. This allows us to “reserve” virtual
swap space and “allocate” swap space when we first touch a page. When we reserve
swap, rather than reserving disk space, we reserve virtual swap space from the
swapfs file system. Disk swap pages are only allocated once a page is paged out.

Есть рыба-пила и есть рыба-молот. Вот только не понятно, что они там строят...

О чем спорим?
Исходя из цитаты вся вся доступная страничная память является частью swapfs .
То есть все, в том числе и то что сейчас занято процесами(выполняемыми в данный момент процессором).

Издеваетесь?