Анализ кучи в R (требуется для решения проблем записи многих графиков в png / jpeg) - PullRequest
Новая
       15

Анализ кучи в R (требуется для решения проблем записи многих графиков в png / jpeg)

1 голос
/ 01 февраля 2011

У меня проблемы с памятью, когда я генерирую много графиков и записываю их на устройства png / jpeg / eps. 

require(ggplot2)
...

render <- function(x) {
  fileName=paste(chartDir, "/", x$PACKED[1], ".png", sep="")
  x <- x[,c("EFF_DATE", "variable", "value")]
  png(fileName, width=1920, height=1000, units="px")
  print(qplot(EFF_DATE, value, data = x, facets = variable ~ ., geom="line"))
  dev.off()      
}

d_ply(molten, "PACKED", render, .progress="tk")

Код неплохо прогрессирует для первых ~ 80 графиков, а затем ведет себя как вилочная бомбапосле этого потребляет 100% оперативной памяти в течение очень короткого времени.Я проверил размеры x, предоставленные qplot, и все они примерно одинаковы, так что это не данные.Код работает нормально, когда я комментирую строку PNG.У меня возникает та же проблема, когда я пытаюсь использовать ggsave из библиотеки ggplot2.

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

С наилучшими пожеланиями, Грэм.

Ответы [ 2 ]

1 голос
/ 02 февраля 2011

Хорошо, похоже, это проблема с моим вызовом qplot (ошибка или ошибка пилота), а не с рендерингом в png / jpeg / eps, как я сначала подумал.

Чтобы воспроизвести, сначала скопируйтевнизу таблицы, в файл с именем "bad.data", а затем введите следующее в приглашении R: 

  require(ggplot2)
  df_import <- read.table("bad.data", colClasses=c("integer", "POSIXct","factor","integer"), header = TRUE)
  qplot(EFF_DATE, value, data = df_import)



        EFF_DATE variable value
147170 2010-07-05  COUNT_0     0
147254 2010-07-06  COUNT_0     0
147338 2010-07-07  COUNT_0     0
147422 2010-07-08  COUNT_0     0
147506 2010-07-09  COUNT_0     0
147590 2010-07-12  COUNT_0     0
147674 2010-07-13  COUNT_0     0
147758 2010-07-15  COUNT_0     0
147842 2010-07-16  COUNT_0     0
147926 2010-07-19  COUNT_0     0
148010 2010-07-20  COUNT_0     0
148094 2010-07-21  COUNT_0     0
148178 2010-07-22  COUNT_0     0
148262 2010-07-23  COUNT_0     0
148346 2010-07-26  COUNT_0     0
148430 2010-07-28  COUNT_0     0
148514 2010-07-29  COUNT_0     0
148598 2010-07-30  COUNT_0     0
148682 2010-08-02  COUNT_0     0
148766 2010-08-03  COUNT_0     0
148850 2010-08-04  COUNT_0     0
148934 2010-08-05  COUNT_0     0
149018 2010-08-06  COUNT_0     0
149102 2010-08-09  COUNT_0     0
149186 2010-08-10  COUNT_0     0
149271 2010-08-11  COUNT_0     0
149356 2010-08-12  COUNT_0     0
149439 2010-08-13  COUNT_0     0
149521 2010-08-16  COUNT_0     0
149601 2010-08-17  COUNT_0     0
149681 2010-08-18  COUNT_0     0
149761 2010-08-19  COUNT_0     0
149843 2010-08-20  COUNT_0     0
149925 2010-08-23  COUNT_0     0
150004 2010-08-24  COUNT_0     0
150084 2010-08-25  COUNT_0     0
150164 2010-08-26  COUNT_0     0
150245 2010-08-27  COUNT_0     0
150326 2010-08-30  COUNT_0     0
150407 2010-08-31  COUNT_0     0

Моя архитектура Linux x86_64, хотя я не уверен, относится ли это кпроблема.

1 голос
/ 01 февраля 2011

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

Вы можете форсировать сборку мусора с помощью функции gc(), которая принимает необязательный параметр verbose. Попробуйте добавить его после dev.off() и посмотрите, поможет ли это.

Jeffrey

...