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

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 bootstrap.mlockall (allows the JVM to lock its memory)

Щас усну...
Прекрасный параметр bootstrap.mlockall который как утверждает дока не даст залезть jvm в swap.
Настраивается в файле: /etc/elasticsearch/elasticsearch.yml

т.к машина у нас дохлая как хуй знает что... т.е:
Mem:  12331016k total, 12252560k used,    78456k free,   116456k buffers
Соответственно elastic стартует с минимальны кол-вом оперативки типа:
-Xms4g -Xmx4g
(я блять такого количества оперативки не видел ни в одном вопросе по elasticsearch в интернете, ну да хуй с ним...)

1. bootstrap.mlockall: true 
lock the process address space into RAM, preventing any Elasticsearch memory from being swapped out.

Проверить что elasticsearch успешно применил этот параметр можно выполнив команду:
[oracle@lal elasticsearch]$ curl http://localhost:9200/_nodes/process?pretty
{
  "cluster_name" : "cluster",
  "nodes" : {
    "DPFEI2HPSGm8eWNCrg3tJw" : {
      "name" : "Node",
      "transport_address" : "inet[/1.1.1.1:9300]",
      "host" : "alal.local",
      "ip" : "1.1.1.1",
      "version" : "1.4.0",
      "build" : "bc94bd8",
      "http_address" : "inet[/1.1.1.1:9200]",
      "process" : {
        "refresh_interval_in_millis" : 1000,
        "id" : 2747,
        "max_file_descriptors" : 65536,
        "mlockall" : false
      }
    }
  }
}

Соответственно тут видно что данная опция не сработала.
Проверяем настройки лимитов для пользователя под которым у нас запускается elasticsearch:
[oracle@lal config]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 96200
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 16384
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Для пользователя oracle выделено пиздец как мало, соответственно добавляем в /etc/security/limits.conf следующие строки:
oracle soft nofile 4024
oracle hard nofile 65536
oracle   soft   nproc    16384
oracle hard nproc 16384
oracle soft stack 10240
oracle hard stack 32768
oracle   hard   memlock    134217728
oracle   soft   memlock    134217728

После перезапуска видим что всё впорядке:

[oracle@lal elasticsearch]$ curl http://localhost:9200/_nodes/process?pretty
{
  "cluster_name" : "cluster",
  "nodes" : {
      "DPFEI2HPSGm8eWNCrg3tJw" : {
      "name" : "Node",
      "transport_address" : "inet[/1.1.1.1:9300]",
      "host" : "alal.local",
      "ip" : "1.1.1.1",
      "version" : "1.4.0",
      "build" : "bc94bd8",
      "http_address" : "inet[/1.1.1.1:9200]",
      "process" : {
        "refresh_interval_in_millis" : 1000,
        "id" : 2747,
        "max_file_descriptors" : 65536,
        "mlockall" : true
      }
    }
  }
}

Комментарии

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

Oracle SOA email notification или какого х.. оно не работает.

От делать нех задокументируем.... Вообщем то всё рассписанно по ссылке: http://www.rubiconred.com/blog/email-notification-with-soa-suite-11g/ Ссылка походу сдохла!!! Придётся на всякий случай записать пока не забыл... Собственно основные настройки делаются на этой странице: Тут будет текст дабы не плодить картинок: MailAccessProtocol : POP3 RetryLimit : -1 MailDelFreq : 600 AutoDelete : not check Debug : not check CheckMailFreq : 30 ReceiveFolder: INBOX OutgoingMailServer :  mail4.ru OutgoingMailServerPort : 25 OutgoingMailServerSecurity : None OutgoingDefaultFromAddr :  pklmn@mail.ru OutgoingPassword: вроде ни чё не трогал... IncomingMailServer: mail3.ru IncomingMailServerPort: 110 IncomingMailServerSSL: not check IncomingMailIDs: pklmn@mail.ru IncomingUserIDs: pklmn IncomingUserPasswords: тут настраиваем пароль При настройке рекомендуется обращать внимания на всплывающие подсказки например: Sender Address должен выглядеть как E...

Weblogic Kerberos

Weblogic установлен на сервере budwf Домен контролер wcctst.wcc.local Клиентская винда XZ 1. Генерим keytab ktpass -princ HTTP/srv_budwf@WCC.LOCAL -mapuser srv_budwf -kvno 0 -crypto AES128-SHA1 -ptype KRB5_NT_PRINCIPAL -pass lalal_1 -out c:\temp\budwf.keytab Т.е в данном случае principal name в keytab полностью соответствует ожиданиям... C:\Users\Administrator>ktpass -princ HTTP/srv_budwf@WCC.LOCAL -mapuser srv_budwf -kv no 0 -crypto AES128-SHA1 -ptype KRB5_NT_PRINCIPAL -pass lalal_1 -out c:\temp\b udwf.keytab Targeting domain controller: wcctst.wcc.local Successfully mapped HTTP/budwf to srv_budwf. Password succesfully set! Key created. Output keytab to c:\temp\budwf.keytab: Keytab version: 0x502 keysize 55 HTTP/budwf@WCC.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x11 (AE S128-SHA1) keylength 16 (0xbf005ae14d58153abe3eab57cf5a8260) C:\Users\Administrator>setspn -L srv_budwf Registered ServicePrincipalNames for CN=srv_budwf,CN=Users,DC=wcc,DC=local: ...

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'...