R ошибка не могу разместить вектор размером

nickleb

Гуру

Сообщения: 961

Зарегистрирован: 22 май 2010, 20:20

Репутация: 152

> tpot<-ncvar_get(ncin,"THETA")
Ошибка: не могу разместить вектор размером 197.8 Mb

rhot

Гуру

Сообщения: 1727

Зарегистрирован: 25 янв 2011, 17:50

Статьи: 1

Репутация: 194

Ваше звание: доктор

Откуда: Архангельск

nickleb

Гуру

Сообщения: 961

Зарегистрирован: 22 май 2010, 20:20

Репутация: 152

nickleb

Гуру

Сообщения: 961

Зарегистрирован: 22 май 2010, 20:20

Репутация: 152

rhot

Гуру

Сообщения: 1727

Зарегистрирован: 25 янв 2011, 17:50

Статьи: 1

Репутация: 194

Ваше звание: доктор

Откуда: Архангельск

gamm

Гуру

Сообщения: 3932

Зарегистрирован: 15 окт 2010, 08:33

Репутация: 1029

Ваше звание: программист

Откуда: Казань

# сохраняем 
prev_address <- tracemem(x)

# отключаем трассировку и изменяем
untracemem(x)
x[3] <- 99

# добавляем ещё одно изменение
x <- 9

# смотрим изменение адреса с предыдущего известного
retracemem(x, previous = prev_address)

Векторы

Векторы элементов атомарных типов, за исключением строкового, имеют только адрес начала вектора. Со строковыми значениями ситуация несколько иная: в R используется так называемый глобальный кэш строковых значений (global string pooling). Это значит, что каждое новое строковое значение получает свой адрес и попадает в кэш, все же дальнейшие обращения к этой строке используют закэшированное значение (то есть обращаются по тому же адресу). Таким образом, вектор строковых значений будет содержать значения из кэша и какое-то количество ссылок на эти значения, которых может быть больше, чем уникальных строковых значений:

x_char <- sample(c('ab', 'ac', 'cb'), 7, replace = TRUE)
x_char <- sort(x_char)
print(x_char)

## [1] "ab" "ac" "ac" "ac" "cb" "cb" "cb"

lobstr::ref(x_char, character = TRUE)

## █ [1:0x561be66ea228] <chr> 
## ├─[2:0x561be68c0458] <string: "ab"> 
## ├─[3:0x561be68c0500] <string: "ac"> 
## ├─[3:0x561be68c0500] 
## ├─[3:0x561be68c0500] 
## ├─[4:0x561be27fbf98] <string: "cb"> 
## ├─[4:0x561be27fbf98] 
## └─[4:0x561be27fbf98]

## [1] "0x561be68c0458" "0x561be68c0500" "0x561be68c0500" "0x561be68c0500"
## [5] "0x561be27fbf98" "0x561be27fbf98" "0x561be27fbf98"

Такая особенность хранения строк может давать ощутимый прирост в оптимизации хранения и использования данных. Помимо очевидного хранения только уникальных строковых значений вместо каждого вхождения, строки можно использовать как альтернативы числовым значениям. В частности, когда в качестве идентификатора наблюдения или еще какого-либо объекта (тех же штрихкодов) используется большое число, можно хранить эти идентификаторы как строковые. За счёт глобального кэша это будет почти так же эффективно, как и с числовыми идентификаторами, так как указатели на адрес в кэше в любом случае числовые. При этом, по опыту, строковое хранение идентификаторов безопаснее для использования (как минимум, нет опасности бесконтрольного перехода в академическую нотацию и использование плавающей точки или же переполнения типа).

Списки и таблицы

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

# создадим список и посмотрим его адрес и адреса его подсписков
my_list <- list(e1 = 1:3, e2 = letters[1:5], e3 = month.abb[1])
lobstr::ref(my_list)

## █ [1:0x561be759a708] <named list> 
## ├─e1 = [2:0x561be61d8a20] <int> 
## ├─e2 = [3:0x561be7fd24f8] <chr> 
## └─e3 = [4:0x561be6321ad8] <chr>

# создаём новый подсписок
my_list$e4 <- sample(5)
lobstr::ref(my_list)

## █ [1:0x561be7e33108] <named list> 
## ├─e1 = [2:0x561be61d8a20] <int> 
## ├─e2 = [3:0x561be7fd24f8] <chr> 
## ├─e3 = [4:0x561be6321ad8] <chr> 
## └─e4 = [5:0x561be7e331f8] <int>

Аналогично с таблицами:

# создаём таблицу и смотрим её адреса
my_df <- data.frame(col1 = 1:5, col2 = letters[1:5], col3 = month.abb[1:5], stringsAsFactors = FALSE)
lobstr::ref(my_df)

## █ [1:0x561be7fe6f18] <df[,3]> 
## ├─col1 = [2:0x561be5dc3f20] <int> 
## ├─col2 = [3:0x561be809a998] <chr> 
## └─col3 = [4:0x561be809a928] <chr>

# создаём новую колонку и смотрим изменения
my_df$col4 <- sample(5)
lobstr::ref(my_df)

## █ [1:0x561be57f2588] <df[,4]> 
## ├─col1 = [2:0x561be5dc3f20] <int> 
## ├─col2 = [3:0x561be809a998] <chr> 
## ├─col3 = [4:0x561be809a928] <chr> 
## └─col4 = [5:0x561be57f26c8] <int>

Copy-on-modify

В R реализован вызов по значению (call-by-value). Правда, в несколько нетрадиционном виде: его корректнее было бы назвать вызовом по соиспользованию (call-by-sharing), в R Internals встречается формулировка call by value illusion. Смысл заключается в следующем: когда мы создаём копию объекта, то первоначально адреса исходного объекта и копии совпадают:

# создаём объект
x <- 1:5

# создаём его копию
y <- x

# смотрим адреса обоих объектов
tracemem(x)

## [1] "<0x561be52e0a00>"

## [1] "<0x561be52e0a00>"

То есть до какого-то момента объект и его копия используют один и тот же адрес в памяти. По-настоящему копия создаётся в тот момент, когда над копией производится какое-то действие:

## tracemem[0x561be52e0a00 -> 0x561be74d9da8]: eval eval withVisible withCallingHandlers handle timing_fn evaluate_call <Anonymous> evaluate in_dir eng_r block_exec call_block process_group.block process_group withCallingHandlers process_file <Anonymous> <Anonymous> do.call eval eval eval eval eval.parent local

Одновременно с механизмом copy-on-modify проявляется и обратная сторона процесса: изменение объекта всегда сопровождается его копированием, в некоторых случаях изменение может быть даже скрыто от пользователя. Например, когда мы хотим добавить к вектору целых значений numeric-значение.

## [1] "integer"

## [1] "<0x561be733eae0>"

## tracemem[0x561be733eae0 -> 0x561be7156318]: eval eval withVisible withCallingHandlers handle timing_fn evaluate_call <Anonymous> evaluate in_dir eng_r block_exec call_block process_group.block process_group withCallingHandlers process_file <Anonymous> <Anonymous> do.call eval eval eval eval eval.parent local 
## tracemem[0x561be7156318 -> 0x561be756c4c8]: eval eval withVisible withCallingHandlers handle timing_fn evaluate_call <Anonymous> evaluate in_dir eng_r block_exec call_block process_group.block process_group withCallingHandlers process_file <Anonymous> <Anonymous> do.call eval eval eval eval eval.parent local

## [1] "numeric"

Как мы видим, сначала за счёт неявного преобразования типов (integer в numeric) происходит копирование и изменение объекта, а потом — происходит добавление нового элемента, также с копированием и созданием объекта новой длины.

Shallow copy

Полное копирование объекта при его изменении (deep copy) — это достаточно дорогостоящая процедура, особенно при больших объемах данных, так как фактически требует двух- или даже трёхкратного объёма памяти объекта для проведения минимальных операций. В частности, из-за такого механизма R долгое время считался очень медленным языком. Тем не менее, в версии 3.1.0 был введён новый механизм копирования — shallow copy, поверхностное копирование. В первую очередь это касается списков и таблиц.

Основная идея механизма — копировать только тот элемент (подсписок или колонку), которая реально изменяется. Остальные элементы оставлять неизменными до тех пор, пока не возникнет какая-то необходимость в их изменении. По сути, механизм shallow copy — сочетание особенности хранения списков в памяти и механизма copy-on-modify.

# создаём таблицу и смотрим её адреса
my_df <- data.frame(col1 = 1:5, col2 = letters[1:5], col3 = month.abb[1:5], stringsAsFactors = FALSE)
lobstr::ref(my_df)

## █ [1:0x561be7fdde68] <df[,3]> 
## ├─col1 = [2:0x561be6ac3310] <int> 
## ├─col2 = [3:0x561be551a3f8] <chr> 
## └─col3 = [4:0x561be56ff338] <chr>

# создаём копию таблицы
my_df_copy <- my_df
lobstr::ref(my_df_copy)

## █ [1:0x561be7fdde68] <df[,3]> 
## ├─col1 = [2:0x561be6ac3310] <int> 
## ├─col2 = [3:0x561be551a3f8] <chr> 
## └─col3 = [4:0x561be56ff338] <chr>

# создаём новую колонку и смотрим изменения
my_df_copy$col1 <- my_df_copy$col1 * 2
my_df_copy$col4 <- sample(5)
lobstr::ref(my_df_copy)

## █ [1:0x561be80abfa8] <df[,4]> 
## ├─col1 = [2:0x561be704b568] <dbl> 
## ├─col2 = [3:0x561be551a3f8] <chr> 
## ├─col3 = [4:0x561be56ff338] <chr> 
## └─col4 = [5:0x561be80ac098] <int>

При копировании таблицы адреса её и копии, а также колонок в таблице и копии совпадали. После изменения первой колонки и создания четвёртой колонки в копии адрес копии и изменённых/созданных колонок изменился. При этом вторая и третья колонки, которые мы не меняли, остались по тому же адресу, что и в исходной таблице, в совместном использовании.

Как следствие, логичным выводом будет, что если мы изменим строку, то изменятся все колонки. То есть это очень невыгодная операция, особенно при больших размерах таблицы: обновлять надо будет полностью всю таблицу, а не только изменяемые колонки:

# смотрим адреса таблицы и колонок
lobstr::ref(my_df_copy)

## █ [1:0x561be80abfa8] <df[,4]> 
## ├─col1 = [2:0x561be704b568] <dbl> 
## ├─col2 = [3:0x561be551a3f8] <chr> 
## ├─col3 = [4:0x561be56ff338] <chr> 
## └─col4 = [5:0x561be80ac098] <int>

# переприсваиваем в строку её же значение (формально ничего не меняется)
my_df_copy[2, ] <- my_df_copy[2, ]

# смотрим ещё раз адреса
lobstr::ref(my_df_copy)

## █ [1:0x561be7e57fd8] <df[,4]> 
## ├─col1 = [2:0x561be7fbd9d8] <dbl> 
## ├─col2 = [3:0x561be7fbd888] <chr> 
## ├─col3 = [4:0x561be7fbd738] <chr> 
## └─col4 = [5:0x561be7e57da8] <int>

Полное обновление таблицы при добавлении строки — одна из причин, почему неэффективны циклы, использующие rbind() в теле цикла.

Modify-in-place

Помимо copy-on-modify, также есть возможность модификации объектов без копирования, на месте, modify-in-place. Подобные модификации возможны для векторов, а также для окружений — при изменении объекта внутри окружения адрес самого окружения не меняется:

# создаём новое окружение и один объект в нём
my_env <- new.env()
my_env$a <- 1:5
lobstr::ref(my_env)

## █ [1:0x561be6007210] <env> 
## └─a = [2:0x561be5fb87b8] <int>

# меняем объект
my_env$a[6] <- 99
lobstr::ref(my_env)

## █ [1:0x561be6007210] <env> 
## └─a = [2:0x561be80cd458] <dbl>

На практике лучше всего (да и полезней) изменение на месте без копирования реализовано в пакете data.table. При изменении колонки вся таблица не копируется, а меняется только колонка или даже её часть.

## █ [1:0x561be7e622e0] <data.table[,3]> 
## ├─col1 = [2:0x561be720e558] <int> 
## ├─col2 = [3:0x561be756c618] <chr> 
## └─col3 = [4:0x561be756cdf8] <chr>

my_dt[, col1 := col1 * 2]
lobstr::ref(my_dt)

## █ [1:0x561be7e622e0] <data.table[,3]> 
## ├─col1 = [2:0x561be7fbcf58] <dbl> 
## ├─col2 = [3:0x561be756c618] <chr> 
## └─col3 = [4:0x561be756cdf8] <chr>

Однако к data.table также применима логика copy-on-modify, что вызывает казусы: когда стандартным путём создаётся и изменяется копия таблицы, изменения также проявляются и в исходной таблице:

# создаём таблицу и её копию
my_dt <- data.table(col1 = 1:5, col2 = letters[1:5], col3 = month.abb[1:5])
my_dt_copy <- my_dt

# смотрим их адреса
lobstr::ref(my_dt)

## █ [1:0x561be7489b50] <data.table[,3]> 
## ├─col1 = [2:0x561be7ee2918] <int> 
## ├─col2 = [3:0x561be5801eb8] <chr> 
## └─col3 = [4:0x561be5801d68] <chr>

## █ [1:0x561be7489b50] <data.table[,3]> 
## ├─col1 = [2:0x561be7ee2918] <int> 
## ├─col2 = [3:0x561be5801eb8] <chr> 
## └─col3 = [4:0x561be5801d68] <chr>

# изменяем колонку в копии таблицы
my_dt_copy[, col1 := col1 * 2]

# смотрим результат
my_dt_copy

##    col1 col2 col3
## 1:    2    a  Jan
## 2:    4    b  Feb
## 3:    6    c  Mar
## 4:    8    d  Apr
## 5:   10    e  May

##    col1 col2 col3
## 1:    2    a  Jan
## 2:    4    b  Feb
## 3:    6    c  Mar
## 4:    8    d  Apr
## 5:   10    e  May

# проверяем на тождество
all.equal(my_dt, my_dt_copy)

## [1] TRUE

# ещё раз смотрим адреса
lobstr::ref(my_dt)

## █ [1:0x561be7489b50] <data.table[,3]> 
## ├─col1 = [2:0x561be74804a8] <dbl> 
## ├─col2 = [3:0x561be5801eb8] <chr> 
## └─col3 = [4:0x561be5801d68] <chr>

## █ [1:0x561be7489b50] <data.table[,3]> 
## ├─col1 = [2:0x561be74804a8] <dbl> 
## ├─col2 = [3:0x561be5801eb8] <chr> 
## └─col3 = [4:0x561be5801d68] <chr>

Для того чтобы избегать подобных ситуаций, следует пользоваться явной функцией копирования data-table объектов — data.table::copy().

x <- rnorm(4000000000)            # Trying to run rnorm function
# Error: cannot allocate vector of size 29.8 Gb

gc()                              # Apply gc() function
#          used (Mb) gc trigger (Mb) max used (Mb)
# Ncells 531230 28.4    1156495 61.8  1156495 61.8
# Vcells 988751  7.6    8388608 64.0  1761543 13.5

x <- rnorm(4000000000)            # Trying to run rnorm function
# Error: cannot allocate vector of size 29.8 Gb

memory.limit()                    # Check currently set limit 
# [1] 16267

memory.limit(size = 35000)        # Increase limit
# [1] 35000

x <- rnorm(4000000000)            # Successfully running rnorm function

В целом:

Примером простого способа размещения XML-данных и получения ответа (как строки) была бы следующая функция:

public string postXMLData(string destinationUrl, string requestXml)
{
    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(destinationUrl);
    byte[] bytes;
    bytes = System.Text.Encoding.ASCII.GetBytes(requestXml);
    request.ContentType = "text/xml; encoding='utf-8'";
    request.ContentLength = bytes.Length;
    request.Method = "POST";
    Stream requestStream = request.GetRequestStream();
    requestStream.Write(bytes, 0, bytes.Length);
    requestStream.Close();
    HttpWebResponse response;
    response = (HttpWebResponse)request.GetResponse();
    if (response.StatusCode == HttpStatusCode.OK)
    {
        Stream responseStream = response.GetResponseStream();
        string responseStr = new StreamReader(responseStream).ReadToEnd();
        return responseStr;
    }
    return null;
}

В вашем конкретная ситуация:

Вместо:

request.ContentType = "application/x-www-form-urlencoded";

use:

request.ContentType = "text/xml; encoding='utf-8'";

Также удалите:

string postData = "XMLData=" + Sendingxml;

И замените:

byte[] byteArray = Encoding.UTF8.GetBytes(postData);

на:

byte[] byteArray = Encoding.UTF8.GetBytes(Sendingxml.ToString());

ответ дан Jaap 16 August 2018 в 10:59

поделиться

bsub -q server_name -R "rusage[mem=requested_memory]" "Rscript script_name.R"

ответ дан David Arenburg 16 August 2018 в 10:59

поделиться

Самый простой способ обойти это ограничение — переключиться на 64 бит R.

ответ дан David Heffernan 16 August 2018 в 10:59

поделиться

Я столкнулся с подобной проблемой, и я использовал 2 флеш-накопителя как «ReadyBoost». Эти два диска обеспечили дополнительную память объемом 8 ГБ (для кеша), и она решила проблему, а также увеличила скорость всей системы в целом. Чтобы использовать Readyboost, щелкните правой кнопкой мыши на диске, перейдите к свойствам и выберите «ReadyBoost» и выберите переключатель «использовать это устройство» и нажмите «Применить» или «ОК» для настройки.

ответ дан Kwaku Damoah 16 August 2018 в 10:59

поделиться

ответ дан Sacha Epskamp 16 August 2018 в 10:59

поделиться

# defrag memory 
save.image(file="temp.RData")
rm(list=ls())
load(file="temp.RData")

ответ дан Simon Woodward 16 August 2018 в 10:59

поделиться

ответ дан tucson 16 August 2018 в 10:59

поделиться

ответ дан Rajib Kumar De 29 October 2018 в 11:55

поделиться

Другие вопросы по тегам:

Похожие вопросы:

0

mytkavish
10 Окт 2021 в 04:57