Запрос питания на нехватку памяти
Обновлено: 01.07.2024
Microsoft Power BI, Analysis Services, DAX, M, MDX, Power Query и Power Pivot
В апрельском выпуске Power BI Desktop функция диагностики запросов Power Query была улучшена, и теперь вы можете возвращать данные счетчиков производительности. Как говорится в сообщении блога:
При запуске счетчиков производительности каждые полсекунды Power Query делает снимок использования ресурсов. Это бесполезно для очень быстрых запросов, но может быть полезно для запросов, использующих гораздо больше ресурсов.
Когда это может быть полезно в реальном мире? В моем последнем сообщении в блоге у меня была диаграмма, показывающая объем данных, которые Power Query считывает с диска при загрузке большого файла JSON, созданного из данных, собранных в Process Monitor с использованием этой техники. Вот еще раз:
Ось x – это относительное время в секундах, прошедшее с момента, когда Power Query начал считывать данные; ось y показывает количество прочитанных данных. Обратите внимание, как данные считываются с постоянной скоростью в течение первых 1,5 секунд, но после отметки в 1,5 секунды пропускная способность выравнивается? Что может быть причиной этого?
Хотя это происходит не всегда, и я не собирал необходимые данные при выполнении этого конкретного теста, ответ, скорее всего, связан с тем, как подсистема Power Query использует память.
Это тема, о которой я уже писал в блоге, и я настоятельно рекомендую, прежде чем продолжить, прочитать этот пост о свойстве Размер контейнера, которое можно задать для потоков данных в Power BI Premium. Вот цитата Курта Хагенлохера из команды разработчиков Power Query из этого сообщения, которая также актуальна здесь, о том, как механизм Power Query использует память при выполнении запроса:
Некоторые операции принудительно перечисляют строки табличного значения. Если сама операция перечисления является дорогостоящей, то использование Table.Buffer может быть оптимизацией производительности, поскольку мы сохраняем значения в памяти, чтобы второе и последующие перечисления строк выполнялись против памяти.
Если только таблица если перечисление выполняется один раз (что является наиболее распространенным сценарием) или если базовое перечисление в любом случае выполняется быстро, то Table.Buffer не улучшит производительность.
Table.Buffer в некоторых случаях может фактически снизить производительность, потому что мы ограничить использование ОЗУ запросом на уровне 256 МБ — это означает, что запрос, который использует более 256 МБ, теперь принудительно выгружает ОЗУ на/с диска. Достаточно разбиения по страницам, и затраты на производительность могут быть весьма значительными.
…
В настоящее время операции «таблицы за раз», такие как объединение, сортировка, множество группировок, поворот, разворот и т. д. , все происходит в оперативной памяти (если не свернуто). Для больших таблиц это потребует много памяти.
Теперь оказывается, что когда Power Query читает файл JSON, он должен загрузить весь файл в память, чего нельзя сказать о других типах источников данных. Так может быть, при чтении файла JSON, использованного в моем тесте, замедление производительности было вызвано пейджингом?
С включенным параметром сбора счетчиков производительности (о том, как это сделать, см. сообщение в блоге с объявлениями), я открыл файл pbix с запросом из моего последнего сообщения в блоге, перешел в редактор Power Query и собрал несколько запросите данные диагностики, щелкнув правой кнопкой мыши последний шаг в моем запросе и выбрав Диагностика:
Вскоре стало ясно, что механизм Power Query имеет пул мэшап-контейнеров, которые он повторно использует (да, идите и прочитайте тот пост в блоге, который я вам посоветовал прочитать!). выполняется запрос. Итак, чтобы получить красивый график, я сделал что-то совершенно неподдерживаемое, но, похоже, все еще работающее: я открыл диспетчер задач и убил все процессы Microsoft Mashup Evaluation Container, которые я мог видеть в Power BI. Сделав это, когда я собрал данные своего счетчика производительности, я смог построить следующий график, показывающий использование памяти Power Query во время оценки запроса:
Ось x показывает количество секунд, прошедших с начала запроса; ось y показывает значение в байтах для счетчиков производительности Commit и Working Set. Желтая линия для счетчика производительности Фиксация (байты) показывает объем виртуальной памяти, используемой Power Query. Синяя линия для счетчика производительности рабочего набора (байт) показывает объем физической памяти, используемой Power Query; как вы можете видеть, он достигает 256 МБ (обозначено красной пунктирной линией) на полпути и никогда не превышает этого значения. Пока фиксация больше, чем рабочий набор, должна происходить подкачка страниц, в результате чего производительность Power Query может снизиться.
За прошедшие годы я обнаружил, что один из наиболее эффективных способов повышения производительности Power Query – избегать преобразований, подобных упомянутым Куртом выше, которые требуют хранения в памяти больших таблиц. Хотя это легче сказать, чем сделать. . По крайней мере, теперь у нас есть простой способ увидеть, где память может вызывать проблемы с производительностью Power Query, используя эту новую функцию.
Ташриф Шариф — разработчик программного обеспечения, ставший техническим писателем. Он обнаружил свой интерес к технологиям после того, как случайно прочитал технический журнал. Теперь он пишет обо всем, что связано с технологиями, от Windows до iOS и потоковых сервисов. Подробнее
- Пользователи сообщают, что не могут использовать PowerBI из-за ошибки Ошибка выделения памяти.
- Обычно это вызвано недостаточным объемом памяти на оборудовании для обработки заданных задач.
- Вы можете увеличить объем доступной памяти, что также работает на виртуальных машинах.
- Кроме того, вы можете попробовать удалить неиспользуемые столбцы, чтобы упростить обработку страницы.
Для решения различных проблем с ПК мы рекомендуем DriverFix:
Это программное обеспечение будет поддерживать ваши драйверы в рабочем состоянии, тем самым защищая вас от распространенных компьютерных ошибок и сбоев оборудования. Проверьте все свои драйверы прямо сейчас, выполнив 3 простых шага:
Power BI — это фантастический инструмент от Microsoft, и хотя он может быть не самым стабильным программным инструментом в своем роде, он, по общему признанию, все еще новый и находится в активной разработке.
Ошибка сбоя выделения памяти в Power BI обычно возникает, если в системе недостаточно памяти для обработки текущей задачи.
Вы можете попытаться закрыть некоторые приложения, выделить больше памяти или внести изменения в исходную таблицу, чтобы исправить эту ошибку, как сообщили пользователи в сообществе Power BI.
Здравствуйте
Я создал файл pbix на 64-битной машине. Размер файла: 22 МБ. Строки: прибл. 5,5 млн.
Данные извлекаются из базы данных MYSQL.
Когда я пытаюсь открыть тот же файл на 32-разрядной машине, появляется сообщение об ошибке
«Не удалось сохранить изменение на сервер. Возвращена ошибка: Ошибка памяти: Ошибка выделения. Если вы используете 32-разрядную версию продукта, рассмотрите возможность обновления до 64-разрядной версии или увеличения объема памяти, доступной на компьютере».
Следуйте советам по устранению неполадок в этой статье, чтобы исправить ошибку, связанную с ошибкой распределения Power BI.
Недостаточно памяти в Power BI
1. Увеличьте объем доступной памяти на Машине
«Загрузка данных».
- Теперь увеличьте максимально допустимую память.
На этом мы завершаем нашу статью о временном выделении памяти в PowerBI. Дайте нам знать, если вы знаете какой-либо другой метод, который мы могли пропустить, и мы соответствующим образом обновим статью.
По-прежнему возникают проблемы? Исправьте их с помощью этого инструмента:
Microsoft Power BI, Analysis Services, DAX, M, MDX, Power Query и Power Pivot
Однако, если вы только что прочитали документацию, вам может быть интересно, что на самом деле делают эти два новых параметра реестра. В этом посте я расскажу только об одном, MaxEvaluationWorkingSetInMB; Я оставлю ForegroundEvaluationContainerCount для следующего поста.
В прошлом я неоднократно писал в блогах о том, как при выполнении запроса Power Query сам запрос выполняется внутри отдельного процесса, называемого оценочным (или гибридным) контейнером, и как этот процесс имеет ограничение на количество памяти, которую он может использовать.Для некоторых преобразований, таких как сортировка таблицы, группировка, поворот и разворот, требуется, чтобы вся таблица данных хранилась в памяти, и если для этих операций требуется больше памяти, чем может использовать контейнер оценки, тогда он запускает разбиение по страницам, и производительность запросов снижается. намного хуже. Этот пост содержит более подробную информацию:
Однако сейчас произошли две вещи. Прежде всего, объем памяти, доступный по умолчанию для ознакомительного контейнера в Power BI Desktop, был увеличен с 256 МБ до 432 МБ. Это само по себе ускорит выполнение многих запросов Power Query. Во-вторых, теперь можно самостоятельно определить, сколько памяти может использовать оценочный контейнер, с помощью нового параметра реестра MaxEvaluationWorkingSetInMB, описанного в документации.
Вот пример, показывающий, какое влияние это может иметь. В Power BI Desktop я создал запрос Power Query, который считывает данные из CSV-файла, содержащего около миллиона строк, а затем сортирует результирующую таблицу по значениям в одном столбце:
Используя SQL Server Profiler способом, описанным здесь, я обнаружил, что запросу Power Query потребовалось почти 87 секунд, чтобы начать возвращать данные, и еще 19 секунд, чтобы вернуть все данные:
Более того, в Диспетчере задач я увидел, что оценочный контейнер, выполняющий работу, использует около 423 МБ ОЗУ:
Затем я использовал Regedit, чтобы установить для параметра MaxEvaluationWorkingSetInMB значение 4096, предоставив каждому оценочному контейнеру максимум 4 ГБ ОЗУ для использования:
После перезапуска рабочего стола я повторно выполнил тот же запрос. На этот раз Диспетчер задач показал, что оценочный контейнер работает, используя около 1,2 ГБ ОЗУ:
… и Profiler показал, что запрос начал возвращать данные уже через 14 секунд, а все данные были возвращены еще через 12 секунд:
Как видите, это значительное улучшение производительности. Однако, прежде чем вы будете слишком увлечены этим, необходимо прояснить несколько вещей.
Во-первых, этот параметр влияет только на производительность запросов Power Query в Power BI Desktop. Это не влияет на производительность запросов в службе Power BI, хотя есть еще один параметр, который (я думаю) будет иметь тот же эффект для запросов, которые проходят через локальный шлюз данных, но это еще один для будущей публикации. Таким образом, хотя это значительно ускорит и упростит разработку, это не ускорит обновление наборов данных в службе Power BI.
Во-вторых, вы должны быть очень осторожны при изменении этого параметра. Здесь нет подстраховки — вы можете установить для MaxEvaluationWorkingSetInMB любое значение, какое хотите, — поэтому требуется некоторая осторожность. Когда набор данных обновляется, для обработки преобразований Power Query может использоваться несколько контейнеров оценки, каждый из которых может использовать объем памяти, указанный MaxEvaluationWorkingSetInMB. Поскольку на вашем компьютере для разработки имеется ограниченный объем памяти, важно не устанавливать для параметра MaxEvaluationWorkingSetInMB слишком большое значение, потому что в этом случае существует риск, что Power BI попытается использовать больше памяти, чем доступно, и остановит ваш компьютер. Более того, нет никакого способа узнать, сколько памяти потребуется для того или иного запроса без некоторых экспериментов, поэтому мой совет: если вы измените MaxEvaluationWorkingSetInMB, вы должны увеличить его только на небольшую величину, а затем увеличить его, только если вы уверены, что он вам нужен. .
Мне бы хотелось узнать, насколько изменение этого параметра повысит эффективность ваших запросов. Если он окажется полезным для большого числа людей, я надеюсь, что мы сможем добавить его в диалоговое окно «Параметры» в Power BI Desktop (что намного удобнее, чем изменение раздела реестра); Я также думаю, что это было бы очень полезно в Excel Power Query. Пожалуйста, оставьте комментарий с вашими выводами!
В Power BI наблюдаются следующие ошибки при нажатии кнопки "Закрыть и применить" после создания запросов с помощью Power Query (M) Builder для Xrm ToolBox.
Ошибка 1:
Если в запрос не вносились никакие изменения, отображается следующее сообщение и данные не отображаются.
Нам не удалось подключиться к вашему источнику данных DirectQuery или внутренней модели. Дважды проверьте правильность имен вашего сервера и базы данных и наличие у вас прав доступа к ним.
Информация об ошибке OLE не найдена. ”
Ошибка 2
Если в запрос не вносились никакие изменения, отображается следующее сообщение и данные не отображаются
Было выдано исключение типа «System.OutOfMemoryException»
Решение:
Это произошло из-за того, что в моих представлениях были поля из связанных сущностей в столбцах, например. Аккаунт (материнская компания).Я удалил их, и запросы работали нормально, поэтому я просто добавил дополнительные запросы для этих связанных сущностей и создал связь между ними.
Возможно, это есть в инструкциях к инструменту Power Query (M) Builder, но если это так, то я пропустил это, и мне потребовалось некоторое время, чтобы понять это. Мне не помогло то, что я только что восстановил свою машину и был уверен, что это проблема с памятью.
Обновление от 04.01.2019:
Я полностью осознаю, что эта ошибка может быть вызвана любым числом или проблемами, поэтому я просто задокументирую другие исправления, которые я обнаружил, когда это произошло снова, в этой статье в качестве обновлений.
Я снова столкнулся с этой ошибкой при попытке обновить существующий запрос после того, как он был объединен и над ним были выполнены другие функции моделирования.
Поскольку проект, над которым я работал, не требовал подключения к каким-либо документам Office (у меня установлена версия Office x86), мне удалось обойти эту ошибку, используя 64-разрядную версию Power BI. Отныне я буду работать в основном с версией x64, если только нет абсолютной необходимости использовать версию x86.
Читайте также: