Ошибки страницы, странное поведение памяти и файлов подкачки - особенно, но не конкретно в R
Я должен сказать с самого начала, что я знаю, что я мог бы, вероятно, сделать с еще большим количеством оперативной памяти, так как в настоящее время я использую 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 предупредила меня, что обычно происходит ошибка с ошибкой страницы.
Возможно, есть упоминание о чем-то похожем на сюжетном форуме:
Я прочитал интересный пост с большим количеством голосов, который я сейчас не могу найти (но думаю, что он был опубликован здесь) относительно файла подкачки, в котором пользователь указал, что на самом деле в Windows никогда не бывает "свободной" ОЗУ; это постоянно заполнено, вещи разбиты на страницы и затем выброшены, если что-то еще нуждается в месте.
Похоже, что существуют некоторые крайне противоречивые мнения о том, следует ли включать файл подкачки.
Я пробовал как включить, так и отключить его, и вижу один и тот же шаблон при возникновении ошибок на странице.
Я, кажется, наблюдаю что-то похожее на модидум на сюжетном форуме. Несмотря на то, что для этих задач, по-видимому, более чем достаточно "доступной" оперативной памяти, R, судя по всему, пытается создать множество файлов.
Мне любопытно, может ли это быть связано с установлением приоритетов памяти в более поздних версиях Windows. Я знаю, что могу повысить приоритет процесса в диспетчере задач, однако действительно ли это увеличивает приоритет выделения памяти, а не только приоритет потока процессора? Есть ли возможность постоянно устанавливать такие приоритеты без использования проприетарного программного обеспечения? Я понимаю, что Windows пытается помочь, упреждающе кэшируя объекты в ОЗУ, однако, на самом деле, это не похоже на помощь с R. Есть ли способ выборочно форсировать или изменять профиль кэширования? Для более интенсивной работы с памятью я бы предпочел, чтобы не было кешированных файлов, которые я на самом деле не использую.
Для тех, кто интересуется твердотельным накопителем, несмотря на то, что он выполняет довольно большое количество операций чтения / записи в файл подкачки и целенаправленно читает и записывает на диск изнутри R (сотни тысяч файлов за раз, насыщая его емкость, затем очищая и снова и снова насыщая его), похоже, что сам SSD работает нормально; Согласно диагностическому инструменту Kingston, в нем нет ничего плохого даже после нескольких лет использования.
Спасибо, что нажали.
1 ответ
Глядя на различный фрагмент кода, который просматривает таблицу UID размером около 10 Мбайт и подставляет вторую таблицу, а также на результаты мониторинга производительности, я заметил, что как только я нажимаю "Выполнить", наблюдается постоянный рост количества сбоев страниц; это будет около 5000/ с минуту или около того, системный кэш постоянно падает. Интересно, что это также похоже на то, что цикл постепенно замедляется.
Я не разработчик, поэтому не могу помочь вам с первой частью вашего вопроса, извините, но как инженер я могу пролить свет на отношения между аппаратным и ОС.
Пожалуйста, поймите, что нет простого способа объяснить это без первого глубокого погружения в фундаментальные различия (и сходства) операционной системы и аппаратного обеспечения платформы. Но здесь идет:
Кроме того, это поможет вам узнать, что на самом базовом уровне вся Платформа представляет собой одну длинную лестницу уровней кэша: либо физический кэш для ЦП ( L1, L2, L3, L4, RAM, HDD и т. Д.), Либо виртуальный кеш уровни для процессов и ОС памяти Mangler. (Обработка частного рабочего набора, рабочего набора, режима ожидания и т. Д.).
Недостатки страницы бывают двух видов: мягкий и жесткий. Ошибка мягкой страницы возникает, когда процесс запрашивает страницу, которая не находится в его рабочем наборе, то есть диапазон адресов, доступных процессу. Страница обычно находится в оперативной памяти как часть "резервного" списка в диспетчере задач (кэшированные файлы).
Описание Standby вводит в заблуждение, потому что на самом деле все страницы, отображаемые ЦП, являются частью рабочего набора системы. Даже кешированные файлы.
Процессор знает расположение запрашиваемой страницы в первичном (RAM) или вторичном (HDD) хранилище - RAM или HDD (уровни кэширования AKA - вы видите?). Это не заботится ни о чем другом.
Процессор не перемещает страницу, он перемещает указатель.
Итак, подведем итоги: мягкая неисправность разбивается на страницы в адресном пространстве процесса и выходит из него - например, рабочий режим установлен в режим ожидания и обратно. Это не очень большая проблема, хотя.
Ошибка жесткого диска возникает, когда запрашиваемая страница находится не в ОЗУ, а в файле подкачки жесткого диска. Жесткие сбои страницы не возникают при выключении файла подкачки (очевидно).
Если 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 ГБ сегментов 2x 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. Есть ли способ выборочно форсировать или изменять профиль кэширования? Для более интенсивной работы с памятью я бы предпочел, чтобы не было кешированных файлов, которые я на самом деле не использую.
Надо кешировать как можно больше
Отличная статья, которая разоблачает много дезинформации: производительность кэша файлов и настройка.