К основному контенту

Weblogic Diagnostic Framework Run Bash Script (reboot managed server) - (bad practices)

Вообщем переодически сервер дохнет по: 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 backup(snapshot) and restore. (Хаотичный набор команд=))

Короче изначально вся эта статья должна была быть про то как наладить скорость восстановления в 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 ?

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",
        "compress": true,
        "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
    }
  } ]

}

Итого бэкап выполнился за 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 -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
      }
    } ]
  }
}

Вообщем то тут видно что восстановление идёт просто пиздец как долго т.е у меня заняло где то 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

тут вообщем то видно что не происходит ровно ни хуя и процесс идёт крайне медленно.


Solution: Update elasticsearch to version 1.7.3!!!

Комментарии

Популярные сообщения из этого блога

Backup elasticsearch with curator.

Сжато кратко, в падлу много расписывать... Вообщем пробуем забэкапить elasticsearch 5.0 с помощью curator 4.2 Что имеем: 2 ноды 1) vapp-cn1 2) vapp-cn2 Репозиторий для бэкапа есть на обоих хостах находится в /backup/el_backup/front права для пользователя под который запущен elasticsearch есть, на обоих нодах в конфиге elasticsearch.yml указанно: path.repo: ["/backup/el_backup/front"] Настройка curator, бэкапить будем все индексы поэтому: 1. snapshot-script.yml actions:   1:     action: snapshot     description: >-       Snapshot logstash- prefixed indices older than 1 day (based on index       creation_date) with the default snapshot name pattern of       'curator-%Y%m%d%H%M%S'.  Wait for the snapshot to complete.  Do not skip       the repository filesystem access check.  Use the other options to create       the snapsho...

Oracle Cloud Control 12c/13c modify target setup Life Cycle Status (emcli, multiple targets)

https://pardydba.wordpress.com/2012/10/17/how-and-why-you-should-set-target-lifecycle-status-properties-in-em12c/+&cd=1&hl=ru&ct=clnk&gl=ru Итак есть куча таргетов middleware, host и т.д ... Менять руками  LifeCycle Status для всех таргетов внутри middleware это геморой поэтому сделать надо это скриптом. По ссылке выше предлагается это сделать для хостов. Ниже будет описано как это сделать для всех таргетов. В краце инструкция такова: Ставим emcli: oracle@omshost$ export JAVA_HOME=$OMS_HOME/../jdk16/jdk oracle@omshost$ export PATH=$JAVA_HOME/bin:$PATH oracle@omshost$ export ORACLE_HOME=$OMS_HOME oracle@omshost$ cd $ORACLE_HOME oracle@omshost$ mkdir emcli oracle@omshost$ java -jar $ORACLE_HOME/sysman/jlib/emclikit.jar client -install_dir=$ORACLE_HOME/emcli Oracle Enterprise Manager 12c Release 2. Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved. EM CLI client-side install completed successfully. oracle@omshost$ $ORACLE_HOME/emcli/emcli...

Weblogic Diagnostic Framework Run Bash Script (reboot managed server) - (bad practices)

Вообщем переодически сервер дохнет по: 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'...