Я должен сказать с самого начала, я знаю, что я, вероятно, мог бы сделать с некоторым количеством ОЗУ больше, так как в настоящее время я использую RStudio на Windows 10 с 4 ГБ ОЗУ. И пост не обязательно связан исключительно с R, но с обработкой памяти в целом. После перезагрузки компьютера и RStudio у меня обычно 2–2,5 ГБ «доступной» оперативной памяти в соответствии с диспетчером задач.

Часть моего кода работает безупречно (особенно когда я использую data.table), даже при том, что это делает довольно много в вычислительном отношении; генерация комбинаций и перестановок, относительно сложных соединений. Другие работы потерпят неудачу 4 из 5 раз с несколько неясными, на первый взгляд случайными ошибками; Например, значение SET_STRING_ELT () должно быть 'CHARSXP'.

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

Я определил некоторые закономерности в этом. Например, это, кажется, связано со временем. Если я вручную перетаскиваю и запускаю секции по частям, это будет работать. И циклы импорта файлов размером 10 МБ с использованием базы R 'read.csv' будут работать вместе с функциями rbindlist для больших файлов; вплоть до «доступного» лимита оперативной памяти в диспетчере задач. Но если я попытаюсь пройтись по импорту 100 МБ файлов базового типа R 'read.csv', ошибка начнет появляться, даже когда я явно удаляю объект из среды, сразу после этого вызываю gc(), очевидно, что это в 10 раз больше Оперативная память доступна в соответствии с диспетчером задач, при новом перезапуске и абсолютно без работы. Единственное решение, которое я придумал для этого, было добавить 10 или более секунд системного сна после каждого цикла gc() и read.csv; что нелепо, когда чтение этих файлов с SSD занимает несколько сотен миллисекунд (Kingston V300, ~ 500 МБ / с), но также работает таинственно (значение SET_STRING_ELT () должно быть ошибкой CHARSXP, исчезают).

В любом случае я планировал провести модернизацию компьютера (купить больше оперативной памяти), но я решил провести некоторое исследование с помощью монитора производительности, выполнив несколько работ, чтобы увидеть, что на самом деле является узким местом для компьютера (если покупать выше. скорость работы ОЗУ того стоит); так как процессор i3 4130t (один из самых дешевых в Intel) редко когда-либо работает выше 50%, при этом все четыре логики явно заняты (с использованием Microsoft MRAN R Open).

Взглянув на различный фрагмент кода, который просматривает таблицу UID размером около 10 МБ и подставляет вторую таблицу, а также на результаты мониторинга производительности, я заметил, что как только я нажимаю «Выполнить», наблюдается постоянный рост количества сбоев страниц; это будет около 5000/ с минуту или около того, системный кэш постоянно падает. Интересно, что это также похоже на то, что цикл постепенно замедляется. Это займет пару минут, чтобы покрыть 5% записей. Но примерно через шесть часов, когда я вернусь, он будет полпути, ползет вперед, и любое небольшое беспокойство заставит R полностью зависнуть. У меня также часто R сбрасывает себя или всю ОС; После синего просмотра часа или нескольких раз подряд Windows предупредила меня, что обычно происходит ошибка с ошибкой страницы.

Возможно, есть упоминание о чем-то похожем на сюжетном форуме:

" Кажется, что он постоянно читает / пишет в файл подкачки.Примерно через 5 минут загрузка процессора составляет 20%, а количество ошибок страниц составляет ~ 15 000 000. Через 10 минут 30% использования ЦП и 65 000 000 сбоев страниц. "

Я прочитал интересный пост с большим количеством голосов, который я сейчас не могу найти (но думаю, что он был опубликован здесь) относительно файла подкачки, в котором пользователь указал, что на самом деле в Windows никогда не бывает «свободной» ОЗУ; он постоянно заполняется, все разбивается на страницы, а затем выгружается, если кому-то еще нужно место.

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

Я пробовал как включить, так и отключить его, и вижу один и тот же шаблон при возникновении ошибок на странице.

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

Мне любопытно, может ли это быть связано с установлением приоритетов памяти в более поздних версиях Windows. Я знаю, что могу повысить приоритет процесса в диспетчере задач, однако действительно ли это увеличивает приоритет выделения памяти, а не только приоритет потока процессора? Есть ли возможность постоянно устанавливать такие приоритеты без использования проприетарного программного обеспечения? Я понимаю, что Windows пытается помочь путем упреждающего кеширования данных в ОЗУ, однако, на самом деле, похоже, что это совсем не помогает с R. Есть ли способ выборочно форсировать или изменять профиль кеширования? Для более интенсивной работы с памятью я бы предпочел, чтобы не было кешированных файлов, которые я на самом деле не использую.

Для всех, кто интересуется твердотельным накопителем, несмотря на то, что он выполняет довольно большое количество операций чтения / записи в файл подкачки и целенаправленно читает и записывает на диск изнутри R (сотни тысяч файлов за раз, насыщая его емкость, затем очищая и снова и снова насыщая его), кажется, что сам SSD работает нормально; Согласно диагностическому инструменту Kingston, в нем нет ничего плохого даже после нескольких лет использования.

Спасибо, что нажали.

1 ответ1

1

Взглянув на различный фрагмент кода, который просматривает таблицу UID размером около 10 МБ и подставляет вторую таблицу, а также на результаты мониторинга производительности, я заметил, что как только я нажимаю «Выполнить», наблюдается постоянный рост количества сбоев страниц; это будет около 5000/ с минуту или около того, системный кэш постоянно падает. Интересно, что это также похоже на то, что цикл постепенно замедляется.

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

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

Кроме того, это поможет вам узнать, что на самом базовом уровне вся Платформа представляет собой одну длинную лестницу уровней кеша, либо физический кеш для ЦП (L1, L2, L3, L4, RAM, HDD и т.д.), Либо Виртуальный кеш уровни для процессов и памяти менеджера памяти. (Обработка частного рабочего набора, рабочего набора, режима ожидания и т.д.).

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

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

Процессор знает расположение запрашиваемой страницы в основном (RAM) или дополнительном (HDD) хранилище - RAM или HDD (уровни кэширования AKA - вы видите?). Это не заботится ни о чем другом.

Процессор не перемещает страницу, он перемещает указатель.

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

Трудная Page Fault происходит , когда запрашиваемая страница не в оперативной памяти , но на странице файл с жесткого диска. Жесткие сбои страницы не возникают при выключении файла подкачки (очевидно).

Если Soft Faults при наличии свободной памяти можно уменьшить, увеличив размер рабочего набора (реестр и редактор объектов групповой политики), добавив ОЗУ или и то, и другое.

Я прочитал интересный пост с большим количеством голосов, который я сейчас не могу найти (но думаю, что он был опубликован здесь) относительно файла подкачки, в котором пользователь указал, что на самом деле в Windows никогда не бывает «свободной» ОЗУ; он постоянно заполняется, все разбивается на страницы, а затем выгружается, если кому-то еще нужно место.

Не правда.

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

Если нет свободного, то машине требуется больше оперативной памяти.

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

Я пробовал как включить, так и отключить его, и вижу один и тот же шаблон при возникновении ошибок на странице.

Файл подкачки был требованием для процессоров Intel IA-32e/Intel-64 с 32-разрядными адресными выводами в ОЗУ под управлением Windows x86 с PAE или Windows 64.

Файл подкачки был единственным способом, которым эти процессоры могли достигать адресов более 4 ГБ, на которые ОС была способна полностью.

Вопреки распространенному мифу, PAE в ОС означает расширение адреса страницы, а не расширение физического адреса. Расширение адреса страницы позволяет адресам, превышающим 4 ГБ, быть доступными для ОС, при условии, что ЦП имеет 36-битные внутренние регистры.

Если расширение адресов страниц включено на процессорах с 32-битными регистрами, все чертовски разрушается. 32/32 ЦП (32 внешних контакта / 32 внутренних регистра) могут достигать адресов до 4 ГБ.

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

E ** Примечание: ранее я неправильно назвал IA-64 x86-64, он должен был прочитать Intel-64.

IA-64 - это х64.

** 32/36 (IA32e/Intel 64) AKA x86-64 может работать с сегментами размером более 4 ГБ, 2 × 4 ГБ. Один сегмент объемом 4 ГБ - это ОЗУ, а другой - файл подкачки. Первичное и вторичное хранилище. RAM ---> CPU: внешние адресные контакты, CPU ------> HDD: внутренние регистры данных.

36-разрядное расширение адреса страницы сокращает адресное пространство на процесс на IA32e/Intel64 до 3,5 ГБ, 512 МБ зарезервировано для каталога таблицы страниц ЦП, а дополнительные 4 бита используются для указателя каталога сегмента

Вы когда-нибудь задумывались, почему скомпилированные игры x87 никогда не используют более 3,6 ГБ? Это потому, что высокие указатели усекаются компилятором Intel. Остальные ~ 512 МБ отмечены как зарезервированные. На 64-битном оборудовании процесс около 500 МБ VAD постоянно помечается как свободное место.

Intel IA-32e/Intel-64 иначе известен как x86-64. x86-64: ЦП с 32 контактами в ОЗУ, поддерживающий страницы 4 ГБ с помощью внутренних регистров и файла подкачки на жестком диске.

Ничто из вышеперечисленного не влияет на оперативную память, между прочим, ЦП с 32 контактами не может обмениваться данными с модулями памяти с плотностью более 4 ГБ. Это аппаратное ограничение.
Это все равно что пытаться позвонить своему другу со стационарного телефона без телефонной линии - просто по телефону. :П


Расширение физического адреса - это номенклатура архитектуры ЦП Intel, относящаяся к контактам адреса ЦП в ОЗУ. Выше четко указано в документации Intel.

Файл подкачки никогда не требовался на процессорах с 36-битными адресными штырьками. (AMD64/IA64)

Кстати, связанные статьи, такие как найденные в Википедии, Technet, MSDN и т.д., Относящиеся к ограничениям памяти Windows и PAE, по большей части полностью ошибочны или вводят в заблуждение.

Microsoft являются худшими преступниками в этом отношении.

Мне любопытно, может ли это быть связано с установлением приоритетов памяти в более поздних версиях Windows. Я знаю, что могу повысить приоритет процесса в диспетчере задач, однако действительно ли это увеличивает приоритет выделения памяти, а не только приоритет потока процессора? Есть ли возможность постоянно устанавливать такие приоритеты без использования проприетарного программного обеспечения? Я понимаю, что Windows пытается помочь путем упреждающего кеширования данных в ОЗУ, однако, на самом деле, похоже, что это совсем не помогает с R. Есть ли способ выборочно форсировать или изменять профиль кеширования? Для более интенсивной работы с памятью я бы предпочел, чтобы не было кешированных файлов, которые я на самом деле не использую.

Надо кешировать как можно больше

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .