Мы разработали модель с использованием машины для повышения градиента (GBM). Эта модель была первоначально разработана с использованием H2O v3.6.0.8 через R v3.2.3 на машине Linux:

$ uname -a
Linux xrdcldapprra01.unix.medcity.net 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Следующий код работает нормально несколько месяцев:

modelname <- 'gbm_34325f.hex'
h2o.gbm(x = predictors, y = "outcome", training_frame = modified.hex,
    validation_frame = modified_holdout.hex, distribution="bernoulli",
    ntrees = 6000, learn_rate = 0.01, max_depth = 5,
    min_rows = 40, model_id = modelname)
gbm <- h2o.getModel(modelname)
h2o.saveModel( gbm, path='.', force = TRUE )

На прошлой неделе мы обновили машину Linux до:

• R: v 3.3.2
• H2O: v 3.10.4.2

Как показано здесь в выходных данных h2o.init():

> h2o.init()
 Connection successful!

R is connected to the H2O cluster: 
    H2O cluster uptime:         2 days 1 hours 
    H2O cluster version:        3.10.4.2 
    H2O cluster version age:    14 days, 22 hours and 48 minutes  
    H2O cluster name:           H2O_started_from_R_bac_ytl642 
    H2O cluster total nodes:    1 
    H2O cluster total memory:   18.18 GB 
    H2O cluster total cores:    64 
    H2O cluster allowed cores:  64 
    H2O cluster healthy:        TRUE 
    H2O Connection ip:          localhost 
    H2O Connection port:        54321 
    H2O Connection proxy:       NA 
    H2O Internal Security:      FALSE 
    R Version:                  R version 3.3.2 (2016-10-31) 

Сейчас я перестраиваю эту модель с нуля в более новой версии R и H2O. Когда я запускаю указанный выше код R / H2O, он зависает от этой команды:

h2o.saveModel( gbm, path='.', force = TRUE )

Пока моя программа зависла на h2o.saveModel, я начал другой сеанс R / H2O и подключился к зависшему в данный момент процессу. Могу успешно получить модель. Я могу успешно запустить h2o.saveModelDetails и сохранить его как JSON. И я могу сохранить его как MOJO. Однако я не могу сохранить его как «шестнадцатеричную» модель через h2o.saveModel.

Это мои команды и результат моего подключенного сеанса (в то время как исходный сеанс остается зависшим):

> h2o.init()
 Connection successful!

R is connected to the H2O cluster: 
    H2O cluster uptime:         2 days 1 hours 
    H2O cluster version:        3.10.4.2 
    H2O cluster version age:    14 days, 22 hours and 48 minutes  
    H2O cluster name:           H2O_started_from_R_bac_ytl642 
    H2O cluster total nodes:    1 
    H2O cluster total memory:   18.18 GB 
    H2O cluster total cores:    64 
    H2O cluster allowed cores:  64 
    H2O cluster healthy:        TRUE 
    H2O Connection ip:          localhost 
    H2O Connection port:        54321 
    H2O Connection proxy:       NA 
    H2O Internal Security:      FALSE 
    R Version:                  R version 3.3.2 (2016-10-31) 

> modelname <- 'gbm_34325f.hex'
> gbm <- h2o.getModel(modelname)
> gbm
Model Details:
==============

H2OBinomialModel: gbm
Model ID:  gbm_34325f.hex 
Model Summary: 
  number_of_trees number_of_internal_trees model_size_in_bytes min_depth
1            6000                     6000           839613730         5
  max_depth mean_depth min_leaves max_leaves mean_leaves
1         5    5.00000          6         32    17.51517
[ snip ]

> model_path <- h2o.saveModelDetails( object=gbm, path='.', force=TRUE )
> model_path
[1] "/home/bac/gbm_34325f.hex.json"

# file created:
# -rw-rw-r-- 1 bac bac      552K Apr  2 12:20 gbm_34325f.hex.json
#
# first few characters are:
# {"__meta":{"schema_version":3,"schema_name":"GBMModelV3","schema_type":"GBMModel"},

> h2o.saveMojo( gbm, path='.', force=TRUE )
[1] "/home/bac/gbm_34325f.hex.zip"

# file created:
# -rw-rw-r-- 1 bac bac   7120899 Apr  2 11:57 gbm_34325f.hex.zip
#
# when I unzip this file, things look okay (altho MOJOs are new to me).

> h2o.saveModel( gbm, path='.', force=TRUE )
[ this hangs and never returns; i have to kill the entire R session ]

# empty file created:
# -rw-rw-r-- 1 bac bac         0 Apr  2 12:00 gbm_34325f.hex

Затем я получаю доступ к этому процессу зависания через веб-интерфейс H2OFlow. Опять же, я могу загрузить и просмотреть модель. Когда я пытаюсь экспортировать модель, создается пустой файл .hex, и я вижу сообщение:

Waiting for 2 responses...

(2 responses потому что я дважды экспортировал.)

1. Снимок экспорта через H2OFlow
2. Снимок сообщения "Ожидание двух ответов" от exportModel

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

Есть идеи о том, что происходит? Спасибо.

ОБНОВИТЬ:

У меня проблема - h2o.saveModel зависает - связана с OOM (нехватка памяти).

Я вижу эти сообщения в .out файле, созданном, когда я h2o.init:

Note:  In case of errors look at the following log files:
    /tmp/RtmpOnJn83/h2o_bfo7328_started_from_r.out
    /tmp/RtmpOnJn83/h2o_bfo7328_started_from_r.err

$ tail -n 6 h2o_bfo7328_started_from_r.out
[ I removed the timestamp / IP info to help made this readable ]

FJ-1-107  INFO:  2017-04-04 01:27:04 30 min 56.196 sec            6000       0.25485          0.22119      0.96950       3.54582                       0.08634
2946-780 INFO: GET /3/Models/gbm_34325f.hex, parms: {}
2946-780 INFO: GET /3/Models/gbm_34325f.hex, parms: {}
946-1102 INFO: GET /99/Models.bin/gbm_34325f.hex, parms: {dir=/opt/app/STUFF/bpci/training/facility_models/gbm_34325f.hex, force=TRUE}
946-1102 WARN: Unblock allocations; cache below desired, but also OOM: OOM, (K/V:3.15 GB + POJO:Zero   + FREE:441.54 GB == MEM_MAX:444.44 GB), desiredKV=299.74 GB OOM!
946-1102 WARN: Unblock allocations; cache below desired, but also OOM: OOM, (K/V:3.15 GB + POJO:Zero   + FREE:441.54 GB == MEM_MAX:444.44 GB), desiredKV=299.74 GB OOM!

Как только я понял, что это проблема OOM, я изменил свой h2o.init на max_mem_size:

localH2O = h2o.init(ip = "localhost", port = 54321, nthreads = -1, max_mem_size = '500G')

Даже при таком высоком значении max_mem_size = '500G' я все равно получаю ошибку OOM (см. Выше).

Когда я запускал H2O v3.6.0.8, я явно не определял max_mem_size.
Мне любопытно: теперь, когда я обновился до H2O v3.10.4.2, увеличилась ли потребность в памяти? Что было по умолчанию max_mem_size в H2O v3.6.0.8?

Есть идеи, что изменилось с точки зрения памяти между двумя версиями H2O? И как я могу заставить это работать снова?

Спасибо!

ОБНОВЛЕНИЕ 11Apr2017:

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

У меня есть общее представление о том, какие параметры вызывают ошибку OOM (нехватка памяти) во время h2o.saveModel.
Вызывает ошибки:

• 51380 записей с 1413 столбцами данных, используемых для обучения
• ntrees = 6000

Не вызывает ошибок:

• 51380 записей с 1413 столбцами данных, используемых для обучения
• ntrees = 3750 (но ntrees = 4000 вызывает ошибку)

Не вызывает ошибок:

• 25000 записей с 1413 столбцами данных, используемых для обучения (но 40000 записей вызывают ошибку)
• ntrees = 6000

Существует некоторая комбинация количества записей, количества столбцов и ntrees, которая в конечном итоге вызывает OOM.

Установка max_mem_size совершенно не помогает. Я установил его на «100ГБ», «200ГБ» и «300ГБ», и все еще OOM в течение h2o.saveModel.

Тестирование более ранних версий H2O

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

После работы с десятью различными версиями h2o я нашел самую последнюю выпущенную версию, которая не создает OOM. Версии и результаты:

1. v3.6.0.8 - успешно (исходная версия использовалась для создания модели)
2. v3.8.1.4 - успех
3. v3.10.0.8 - успех
4. v3.10.2.1 - успех
5. v3.10.3.1 - ошибка: OOM
6. v3.10.3.2 - ошибка: OOM
7. v3.10.3.5 - ошибка: OOM
8. v3.10.4.2 - ошибка: OOM (обновлено до этого; обнаружена ошибка OOM)
9. v3.10.4.3 - ошибка: OOM
10. v3.11.0.3839 - успех

Я не использую версию 3.11.0.3839, поскольку она кажется «передовой». В настоящее время я работаю с v3.10.2.1.

Надеюсь, это поможет кому-нибудь отследить эту ошибку.

ОБНОВЛЕНИЕ 23Jun2017:

Мне удалось решить эту проблему:

1. обновление до v3.10.5.1
2. установка обоих min_mem_size и max_mem_size в течение h2o.init()

См .: https://stackoverflow.com/a/44724813/7733787