간단히 발표용으로 정리해서 slideshare에 업로드 해둠

 - 링크 : https://www.slideshare.net/seunghaeom/elk-apmwith-66


데모를 통한 시연에 시간을 많이 썻고, 어느정도 배경지식이 있다는 전제하이기 때문에 기초적인 부분은 모두 생략

'ElasticSearch > ELK' 카테고리의 다른 글

ELK APM(with 6.6 살펴보기) - #2  (0) 2019.02.18
ELK APM(with 6.6 살펴보기) - #1  (0) 2019.02.18
ELK 2.3.1 퀵 설치  (0) 2016.08.07
1편에서 기본 준비를 완료하였고 해당 문서는 테스트를 위한 내용을 담음

  1. java
    1. 테스트용 프로그램을 만들어서 서버에서 실행
      1. 테스트프로그램 다운로드 : wget  'https://github.com/oshnew/ELK-Study/raw/master/apm/sample-program/hello-demo.jar' -O hello-demo.jar
        1. 참고: APM agent없이 배포 : java -jar -Dserver.port=8700 hello-demo.jar
        2. APM agent와 함께 실행
java \
 -javaagent:elastic-apm-agent-1.3.0.jar\
 -Delastic.apm.service_name=hello-demo\
 -Delastic.apm.server_url=http://localhost:8200\
 -Delastic.apm.application_packages=org.example\
 -jar -Dserver.port=9878 hello-demo.jar


        1. 트래픽 발생
        2. 확인(로컬 Virtual box에서 실행 함)
    

'ElasticSearch > ELK' 카테고리의 다른 글

ELK APM(with 6.6 살펴보기) - slideshare버전 링크  (0) 2019.02.18
ELK APM(with 6.6 살펴보기) - #1  (0) 2019.02.18
ELK 2.3.1 퀵 설치  (0) 2016.08.07
  • 개인 메모 목적의 글입니다.
  • ELK 2.x 부터 5.0까지 사용하다가 오랜만에 최신 버전을 설치(+ APM기능 확인 목적)해보는 중입니다.


  1. 목적
    1. ELK APM을 설치 후 데모를 실행(ELK는 19년 2월 기준으로 최신 버전인 6.6버전)
    2. 몇 가지 언어로 프로그램을 만든 후 부하를 발생시키고 결과를 확인하는 과정에서 학습
      1. 기존 APM인 Pinpoint 등을 대체하거나 미 사용했던 언어 APM의 효용성 확인

  2. 사전 조사 자료
    1. 공식 문서
      1. 19년 2월 12일 기준 버전 6.6
        1. Elasticsearch와 필요 JVM : Oracle/OpenJDK**11 필요(링크)
    2. 지원언어(또는 프레임웤)
      1. Java
      2. Node.js
      3. Django
      4. Flask
      5. Rails
      6. Rack
      7. RUM - JS
      8. Go

  3. APM 구성 Components(참고 링크)
    1. Elasticsearch : full-text search & 분석엔진. 데이터 저장소, 검색이 수행됨. APM Agents에서 전송된 데이터가 최종적으로 저장됨
    2. Kibana : 시각화 컴포넌트, Elasticsearch에 질의를 요청하고 화면에 시각화 처리 함
    3. APM agents : 서비스와 동일한 언어로 개발된 client side의 프로그램. 서비스의 성능 관련 데이터와 에러 데이터를 런타임에 APM서버로 전송
    4. APM Server : Go로 작성된서버이며 APM agents로부터 데이터를 JSON HTTP API로 전송 받아서 documents(Elasticserarch의 데이터 row단위)를 만들어서 Elasticsearch에 저장함

  4. 설치방법
    1. Elasticsearch
      1. 6.6버전은 open jdk 11설치(참고 링크)
      2. elasticserarch 6.6설치 링크 
    2. Kibana
      1. config/kibana.yml 파일에서 server.host: "0.0.0.0" 로 변경하면 모든 IP에서 웹 접근이 허용 됨




 오늘은 일단 APM Componets 중 Elasticsearch와 kibana 까지 설치 후 로컬PC에서 샘플이 작동 함 - Virtualbox 포트포워딩 처리 함. OS는 CentOS



'ElasticSearch > ELK' 카테고리의 다른 글

ELK APM(with 6.6 살펴보기) - slideshare버전 링크  (0) 2019.02.18
ELK APM(with 6.6 살펴보기) - #2  (0) 2019.02.18
ELK 2.3.1 퀵 설치  (0) 2016.08.07

apache http client의 타임아웃 관련(기본 값 등) - 버전마다 틀릴 수 있으며 아래는 4.5.3 기준





* 요약 

 - 0으로 셋팅하면 무한이고, 음수로 셋팅하면 OS 시스템의 기본값을 따른다.

 - 리눅스 계열에서 시스템 기본값은 net.ipv4  timeout time wait쪽을 살펴보면 되는 것 같음

      




[참고 - 소스]


 /**

     * Determines the timeout in milliseconds until a connection is established.

     * A timeout value of zero is interpreted as an infinite timeout.

     * <p>

     * A timeout value of zero is interpreted as an infinite timeout.

     * A negative value is interpreted as undefined (system default).

     * </p>

     * <p>

     * Default: {@code -1}

     * </p>

     */

    public int getConnectTimeout() {

        return connectTimeout;

    }

/**

* Request Checker

*  - Redirect

*

* @param modelAndView

* @return

*/

private boolean isRedirect(ModelAndView modelAndView) {

return modelAndView.getView() instanceof RedirectView || modelAndView.getViewName().startsWith("redirect:");

}

  •  요약
    • G1 GC worst-case에서 향상 목적
    • JDK9부터 기본 GC가 G1으로 변경되었는데, concurrent GC에서 full GC가 발생 할 수 있음. 
    • G1 GC의 알고리즘 mark-sweep-compact를 병렬로 수행하도록 변경되었으며 -XX:ParallelGCThreads 옵션을 사용해서 스레드 수 조정 가능


JEP 307: Parallel Full GC for G1

Owner Stefan Johansson
Type Feature
Scope Implementation
Status Closed / Delivered
Release 10
Component hotspot / gc
Discussion hotspot dash gc dash dev at openjdk dot java dot net
Effort M
Duration M
Reviewed by Mikael Vidstedt
Endorsed by Mikael Vidstedt
Created 2017/01/17 11:40
Updated 2018/03/29 07:39
Issue 8172890

Summary

Improve G1 worst-case latencies by making the full GC parallel.

Non-Goals

Match the performance of the parallel collector's full GC for all use cases.

Motivation

The G1 garbage collector was made the default in JDK 9. The previous default, the parallel collector, has a parallel full GC. To minimize the impact for users experiencing full GCs, the G1 full GC should be made parallel as well.

Description

The G1 garbage collector is designed to avoid full collections, but when the concurrent collections can't reclaim memory fast enough a fall back full GC will occur. The current implementation of the full GC for G1 uses a single threaded mark-sweep-compact algorithm. We intend to parallelize the mark-sweep-compact algorithm and use the same number of threads as the Young and Mixed collections do. The number of threads can be controlled by the -XX:ParallelGCThreads option, but this will also affect the number of threads used for Young and Mixed collections.

Testing

  • Full GC time analysis to ensure that the full GC times have improved. Looking at benchmark scores will probably not be good enough since G1 is designed to avoid full GCs.
  • Runtime analysis using VTune or Solaris Studio Performance Analyzer to find unnecessary bottlenecks.

Risks and Assumptions

  • The work is based on the assumption that nothing in the fundamental design of G1 prevents a parallel full GC.
  • The fact that G1 uses regions will most likely lead to more wasted space after a parallel full GC than for a single threaded one.

+ Recent posts