Вообщем переодически сервер дохнет по: The WebLogic Server encountered a critical failure java.lang.OutOfMemoryError: Metaspace Reason: There is a panic condition in the server. The server is configured to exit on panic И хотя это гавно пишет типа Reason: There is a panic condition in the server. The server is configured to exit on panic чёт ни хуя он ни куда не exit.... Вообщем т.к разбираться с тем чем он жрётся нет ни времени ни желания (оно обязательно появится)... как вариант можно приделать костыль... костыль будет заключаться в ребуте сервера при возникновении этой ошибки. Что значит для этого надо... Желания и понимание что так жить нельзя, и вообще... Делаем новый модуль называем скажем: Reboot-OOMMetaSpace Идём в в новый модуль делаем Policy: Называем его OOM-Metaspace и говорит что это Server log: Жмём next в Configuration Policy пишем: log.logMessage.contains('java.lang.OutOfMemoryError: Metaspace'...
Короче изначально вся эта статья должна была быть про то как наладить скорость восстановления в elasticsearch... но как выяснилось в версии elasticsearch-1.7.3-1.noarch уже всё пофиксили и всё "летает"
Но всё же пост оставлю как хуй знает что б был...
Пара ссылок для версии 1.7 (да да уже 2.1)
https://www.elastic.co/guide/en/elasticsearch/reference/1.7/modules-snapshots.html
https://www.elastic.co/guide/en/elasticsearch/reference/1.7/indices-recovery.html
Итак snapshot и restore elasticsearch...
Для начала не плохо было бы узнать скорость диска
Проверяем скорость чтения:
hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 416 MB in 3.01 seconds = 138.42 MB/sec
Проверяем скорость записи:
time cp 2giga.file /media/data
= 140Mb/sec
time dd if=/dev/zero of=/media/data/2giga.file oflag=direct bs=2G count=1 ?
Соответственно если мы хотим что бы весь диск работал на команду snapshot то при создании репозитория можно указать полученные значения.
Первое что надо сделать это указать путь к репозиторию:
vi /etc/elasticsearch/elasticsearch.yml
path.repo: ["/media/data/elasticbackup"]
Далее создаём сам репозиторий сделать это можно в kopf или командой т.к команду мне писать в падлу делать будем это делать в kopf.
Создание репозитория из консольки для ебанутых случаев:
curl -XPUT 'http://localhost:9200/_snapshot/elasticbackup' -d '{
"type": "fs",
"settings": {
"location": "/media/data/elasticbackup",
"compress": true,
"max_restore_bytes_per_sec": "140mb",
"max_snapshot_bytes_per_sec": "140mb"
}
}'
По поводу опции compress судя по описанию она на хер не нужна.
Далее можно начать выполнять backup индекс размером 50+Gb:
curl -XPUT http://localhost:9200/_snapshot/elbackup/prod-30.10.2015 -d '
{
"indices": "prod",
"ignore_unavailable": "true",
"include_global_state": false
}'
Во время выполнения можно посмотреть iostat
iostat
]# iostat -k /dev/sdb 5 5
Linux 2.6.39-400.109.5.el6uek.x86_64 10/30/2015 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
4.66 1.82 0.55 0.19 0.00 92.78
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 14.33 251.11 445.67 2953036833 5241100944
avg-cpu: %user %nice %system %iowait %steal %idle
4.25 2.20 9.50 21.07 0.00 62.98
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 1341.40 135160.00 131732.80 675800 658664
avg-cpu: %user %nice %system %iowait %steal %idle
4.60 2.72 10.16 21.05 0.00 61.46
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 1330.40 136688.80 133021.60 683444 665108
avg-cpu: %user %nice %system %iowait %steal %idle
5.53 2.81 11.61 23.11 0.00 56.94
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 1356.40 135712.00 149041.60 678560 745208
avg-cpu: %user %nice %system %iowait %steal %idle
6.28 3.08 13.50 22.27 0.00 54.88
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 1301.60 132299.20 133584.80 661496 667924
Как видно диск работает по полной
]$ curl -XGET 'http://localhost:9200/_snapshot/elbackup/_all?pretty'
{
"snapshots" : [ {
"snapshot" : "prod-30.10.2015",
"indices" : [ "prod" ],
"state" : "SUCCESS",
"start_time" : "2015-10-30T13:53:19.987Z",
"start_time_in_millis" : 1446213199987,
"end_time" : "2015-10-30T14:00:35.347Z",
"end_time_in_millis" : 1446213635347,
"duration_in_millis" : 435360,
"failures" : [ ],
"shards" : {
"total" : 2,
"failed" : 0,
"successful" : 2
}
} ]
}
Итого бэкап выполнился за 435360 ms=7min.
Восстановление:
curl -XPOST http://localhost:9200/_snapshot/elbackup/prod-30.10.2015/_restore?wait_for_completion=true
Мониторинг процесса восстановления:
curl -XGET http://localhost:9200/retail_prod/_recovery?pretty=true
Просмотр информации о репозитории:
curl -XGET 'http://localhost:9200/_snapshot/_all?pretty'
Просмотр информации о конкретном snapshot:
curl -XGET http://localhost:9200/_snapshot/elbackup/count-16.12.2015?pretty
Удаление конкретного бэкапа:
curl -XDELETE http://localhost:9200/_snapshot/elbackup/count-16-12-2015
Тут описан набор бесполезных действий которые вам НИ КАК НЕ ПОМОГУТ!
Основные проблемы начинаются при попытке восстановить сие творение:
]$ curl -XGET http://localhost:9200/prod/_recovery?pretty=true
{
"prod" : {
"shards" : [ {
"id" : 0,
"type" : "SNAPSHOT",
"stage" : "DONE",
"primary" : true,
"start_time_in_millis" : 11763661898,
"stop_time_in_millis" : 11768039490,
"total_time_in_millis" : 4377592,
"source" : {
"repository" : "elbackup",
"snapshot" : "prod-30.10.2015",
"index" : "prod"
},
"target" : {
"id" : "Nu1DE9qhQ9molULaB7fo1Q",
"host" : "logstash",
"transport_address" : "inet[/:9301]",
"ip" : "",
"name" : "Logstash Node"
},
"index" : {
"size" : {
"total_in_bytes" : 29761643096,
"reused_in_bytes" : 29761643096,
"recovered_in_bytes" : 29761643096,
"percent" : "100.0%"
},
"files" : {
"total" : 169,
"reused" : 0,
"recovered" : 169,
"percent" : "100.0%"
},
"total_time_in_millis" : 4363469,
"source_throttle_time_in_millis" : 0,
"target_throttle_time_in_millis" : 0
},
"translog" : {
"recovered" : 0,
"total" : 0,
"percent" : "100.0%",
"total_on_start" : 0,
"total_time_in_millis" : 0
},
"start" : {
"check_index_time_in_millis" : 0,
"total_time_in_millis" : 14123
}
}, {
"id" : 1,
"type" : "SNAPSHOT",
"stage" : "DONE",
"primary" : true,
"start_time_in_millis" : 11763661909,
"stop_time_in_millis" : 11767458680,
"total_time_in_millis" : 3796771,
"source" : {
"repository" : "elbackup",
"snapshot" : "prod-30.10.2015",
"index" : "prod"
},
"target" : {
"id" : "Nu1DE9qhQ9molULaB7fo1Q",
"host" : "logstash",
"transport_address" : "inet[/19301]",
"ip" : "",
"name" : "Logstash Node"
},
"index" : {
"size" : {
"total_in_bytes" : 25627354664,
"reused_in_bytes" : 25627354664,
"recovered_in_bytes" : 25627354664,
"percent" : "100.0%"
},
"files" : {
"total" : 155,
"reused" : 0,
"recovered" : 155,
"percent" : "100.0%"
},
"total_time_in_millis" : 3783927,
"source_throttle_time_in_millis" : 0,
"target_throttle_time_in_millis" : 0
},
"translog" : {
"recovered" : 0,
"total" : 0,
"percent" : "100.0%",
"total_on_start" : 0,
"total_time_in_millis" : 0
},
"start" : {
"check_index_time_in_millis" : 0,
"total_time_in_millis" : 12784
}
} ]
}
}
Вообщем то тут видно что восстановление идёт просто пиздец как долго т.е у меня заняло где то 70 минут... тут https://www.elastic.co/guide/en/elasticsearch/guide/current/indexing-performance.html пишут типа сделать:
curl -XPUT http://localhost:9200/_cluster/settings -d '
{
"transient" : {
"indices.store.throttle.type" : "none"
}
}'
Полная херня по крайней мере при recover index она явно не задействована.
Вообщем то можно проверить:
]$ curl -XGET http://localhost:9200/_cluster/settings?pretty
{
"persistent" : { },
"transient" : {
"indices" : {
"store" : {
"throttle" : {
"type" : "merge"
}
}
}
}
}
Меняем:
curl -XPUT http://localhost:9200/_cluster/settings -d '
{
"transient" : {
"indices.store.throttle.type" : "none"
}
}'
Запускаем импорт (лучше запускать из командной строки дабы всегда иметь возможность жмакнуть ctrl+c)
curl -XPOST http://localhost:9200/_snapshot/elbackup/prod-30.10.2015/_restore?wait_for_completion=true
После выполнения в kopf видим что собстна индекс появился и recover пошёл:
Собственно процесс восстановления можно мониторить запросом описанным выше:
curl -XGET http://localhost:9200/prod/_recovery?pretty=true
Можно так же посмотреть
]# iostat -k /dev/sdb 2 100
Linux 2.6.39-400.109.5.el6uek.x86_64 11/02/2015 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
4.62 1.87 0.55 0.21 0.00 92.75
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 14.30 261.29 459.95 3137122257 5522386496
avg-cpu: %user %nice %system %iowait %steal %idle
1.97 14.52 1.97 18.26 0.00 63.28
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 117.00 13416.00 602.00 26832 1204
тут вообщем то видно что не происходит ровно ни хуя и процесс идёт крайне медленно.
Но всё же пост оставлю как хуй знает что б был...
Пара ссылок для версии 1.7 (да да уже 2.1)
https://www.elastic.co/guide/en/elasticsearch/reference/1.7/modules-snapshots.html
https://www.elastic.co/guide/en/elasticsearch/reference/1.7/indices-recovery.html
Итак snapshot и restore elasticsearch...
Для начала не плохо было бы узнать скорость диска
Проверяем скорость чтения:
hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 416 MB in 3.01 seconds = 138.42 MB/sec
time cp 2giga.file /media/data
= 140Mb/sec
time dd if=/dev/zero of=/media/data/2giga.file oflag=direct bs=2G count=1 ?
Backup
Соответственно если мы хотим что бы весь диск работал на команду snapshot то при создании репозитория можно указать полученные значения.
Первое что надо сделать это указать путь к репозиторию:
vi /etc/elasticsearch/elasticsearch.yml
path.repo: ["/media/data/elasticbackup"]
Далее создаём сам репозиторий сделать это можно в kopf или командой т.к команду мне писать в падлу делать будем это делать в kopf.
Создание репозитория из консольки для ебанутых случаев:
curl -XPUT 'http://localhost:9200/_snapshot/elasticbackup' -d '{
"type": "fs",
"settings": {
"location": "/media/data/elasticbackup",
"max_restore_bytes_per_sec": "140mb",
"max_snapshot_bytes_per_sec": "140mb"
}
}'
По поводу опции compress судя по описанию она на хер не нужна.
compress |
Turns on compression of the snapshot files. Compression is applied only to metadata files (index mapping and settings). Data files are not compressed. Defaults to
true . |
Далее можно начать выполнять backup индекс размером 50+Gb:
curl -XPUT http://localhost:9200/_snapshot/elbackup/prod-30.10.2015 -d '
{
"indices": "prod",
"ignore_unavailable": "true",
"include_global_state": false
}'
Во время выполнения можно посмотреть iostat
iostat
]# iostat -k /dev/sdb 5 5
Linux 2.6.39-400.109.5.el6uek.x86_64 10/30/2015 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
4.66 1.82 0.55 0.19 0.00 92.78
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 14.33 251.11 445.67 2953036833 5241100944
avg-cpu: %user %nice %system %iowait %steal %idle
4.25 2.20 9.50 21.07 0.00 62.98
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 1341.40 135160.00 131732.80 675800 658664
avg-cpu: %user %nice %system %iowait %steal %idle
4.60 2.72 10.16 21.05 0.00 61.46
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 1330.40 136688.80 133021.60 683444 665108
avg-cpu: %user %nice %system %iowait %steal %idle
5.53 2.81 11.61 23.11 0.00 56.94
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 1356.40 135712.00 149041.60 678560 745208
avg-cpu: %user %nice %system %iowait %steal %idle
6.28 3.08 13.50 22.27 0.00 54.88
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 1301.60 132299.20 133584.80 661496 667924
Как видно диск работает по полной
]$ curl -XGET 'http://localhost:9200/_snapshot/elbackup/_all?pretty'
{
"snapshots" : [ {
"snapshot" : "prod-30.10.2015",
"indices" : [ "prod" ],
"state" : "SUCCESS",
"start_time" : "2015-10-30T13:53:19.987Z",
"start_time_in_millis" : 1446213199987,
"end_time" : "2015-10-30T14:00:35.347Z",
"end_time_in_millis" : 1446213635347,
"duration_in_millis" : 435360,
"failures" : [ ],
"shards" : {
"total" : 2,
"failed" : 0,
"successful" : 2
}
} ]
}
Восстановление:
curl -XPOST http://localhost:9200/_snapshot/elbackup/prod-30.10.2015/_restore?wait_for_completion=true
Мониторинг процесса восстановления:
curl -XGET http://localhost:9200/retail_prod/_recovery?pretty=true
Просмотр информации о репозитории:
curl -XGET 'http://localhost:9200/_snapshot/_all?pretty'
Просмотр информации о конкретном snapshot:
curl -XGET http://localhost:9200/_snapshot/elbackup/count-16.12.2015?pretty
Удаление конкретного бэкапа:
curl -XDELETE http://localhost:9200/_snapshot/elbackup/count-16-12-2015
curl -XPOST 'http://localhost:9200/_snapshot/my_backup/_verify'
Далее проблемы для версии elasticsearch ниже 1.7.3 (я хз какой точно у меня на 1.7.3 всё ок=))
Тут описан набор бесполезных действий которые вам НИ КАК НЕ ПОМОГУТ!Основные проблемы начинаются при попытке восстановить сие творение:
]$ curl -XGET http://localhost:9200/prod/_recovery?pretty=true
{
"prod" : {
"shards" : [ {
"id" : 0,
"type" : "SNAPSHOT",
"stage" : "DONE",
"primary" : true,
"start_time_in_millis" : 11763661898,
"stop_time_in_millis" : 11768039490,
"total_time_in_millis" : 4377592,
"source" : {
"repository" : "elbackup",
"snapshot" : "prod-30.10.2015",
"index" : "prod"
},
"target" : {
"id" : "Nu1DE9qhQ9molULaB7fo1Q",
"host" : "logstash",
"transport_address" : "inet[/:9301]",
"ip" : "",
"name" : "Logstash Node"
},
"index" : {
"size" : {
"total_in_bytes" : 29761643096,
"reused_in_bytes" : 29761643096,
"recovered_in_bytes" : 29761643096,
"percent" : "100.0%"
},
"files" : {
"total" : 169,
"reused" : 0,
"recovered" : 169,
"percent" : "100.0%"
},
"total_time_in_millis" : 4363469,
"source_throttle_time_in_millis" : 0,
"target_throttle_time_in_millis" : 0
},
"translog" : {
"recovered" : 0,
"total" : 0,
"percent" : "100.0%",
"total_on_start" : 0,
"total_time_in_millis" : 0
},
"start" : {
"check_index_time_in_millis" : 0,
"total_time_in_millis" : 14123
}
}, {
"id" : 1,
"type" : "SNAPSHOT",
"stage" : "DONE",
"primary" : true,
"start_time_in_millis" : 11763661909,
"stop_time_in_millis" : 11767458680,
"total_time_in_millis" : 3796771,
"source" : {
"repository" : "elbackup",
"snapshot" : "prod-30.10.2015",
"index" : "prod"
},
"target" : {
"id" : "Nu1DE9qhQ9molULaB7fo1Q",
"host" : "logstash",
"transport_address" : "inet[/19301]",
"ip" : "",
"name" : "Logstash Node"
},
"index" : {
"size" : {
"total_in_bytes" : 25627354664,
"reused_in_bytes" : 25627354664,
"recovered_in_bytes" : 25627354664,
"percent" : "100.0%"
},
"files" : {
"total" : 155,
"reused" : 0,
"recovered" : 155,
"percent" : "100.0%"
},
"total_time_in_millis" : 3783927,
"source_throttle_time_in_millis" : 0,
"target_throttle_time_in_millis" : 0
},
"translog" : {
"recovered" : 0,
"total" : 0,
"percent" : "100.0%",
"total_on_start" : 0,
"total_time_in_millis" : 0
},
"start" : {
"check_index_time_in_millis" : 0,
"total_time_in_millis" : 12784
}
} ]
}
}
curl -XPUT http://localhost:9200/_cluster/settings -d '
{
"transient" : {
"indices.store.throttle.type" : "none"
}
}'
Полная херня по крайней мере при recover index она явно не задействована.
Вообщем то можно проверить:
]$ curl -XGET http://localhost:9200/_cluster/settings?pretty
{
"persistent" : { },
"transient" : {
"indices" : {
"store" : {
"throttle" : {
"type" : "merge"
}
}
}
}
}
curl -XPUT http://localhost:9200/_cluster/settings -d '
{
"transient" : {
"indices.store.throttle.type" : "none"
}
}'
Запускаем импорт (лучше запускать из командной строки дабы всегда иметь возможность жмакнуть ctrl+c)
curl -XPOST http://localhost:9200/_snapshot/elbackup/prod-30.10.2015/_restore?wait_for_completion=true
После выполнения в kopf видим что собстна индекс появился и recover пошёл:
Собственно процесс восстановления можно мониторить запросом описанным выше:
curl -XGET http://localhost:9200/prod/_recovery?pretty=true
Можно так же посмотреть
]# iostat -k /dev/sdb 2 100
Linux 2.6.39-400.109.5.el6uek.x86_64 11/02/2015 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
4.62 1.87 0.55 0.21 0.00 92.75
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 14.30 261.29 459.95 3137122257 5522386496
avg-cpu: %user %nice %system %iowait %steal %idle
1.97 14.52 1.97 18.26 0.00 63.28
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 117.00 13416.00 602.00 26832 1204
Комментарии
Отправить комментарий