일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 톰캣
- 몽고DB
- 확인
- apache
- tomcat
- Pipeline
- 성능
- slowQuery
- troubleshooting
- 인덱스
- aggregation
- 진행
- maven
- kill
- 무중단
- 상태
- LocalRepository
- projection
- deploy
- longQuery
- 배포
- GRACEFUL
- was
- MongoDB
- 테크블로그
- web
- restart
- NoSQL
- httpd
- no space left
- Today
- Total
목록Server, Infra (3)
boogie의 가벼운 개발 일기
세번째 시도 // Worker의 Status를 직접 제어하자 (성공) jk status (status worker) 또는 graceful restart jk status manager의 web view 화면. 이런게 웹 포트가 열려있다니 방화벽으로 막는다고 해도 꺼림칙하다.. js status manager worker의 상태를 관리하는 worker를 별도로 띄운다 해당 status worker에 GET 요청을 날려서 worker의 상태를 확인하거나 변경할수 있음 해당 페이지에 접근하게되면 서버들을 모두 disable 할 수 있기때문에 보안상 좋은 방법은 아니라고 생각함 apache graceful restart 서버에서 설정파일을 직접 변경, 아파치를 reload하는 방식 장점 : apache grac..
회사 위키로 공유했던 내용 옮겨적기 .. 어떤 방식으로 할 것인가 무중단 배포의 방식 Rolling Blue/Green Canary 일부 User(ex. 내부 테스터)만 새로운 버전으로 접근되도록 한 상태에서 모든 검증을 마친 뒤 전 사용자 대상으로 오픈한다 별도의 인프라를 구성하여 라우터에서 분기하거나, (모든 요청이 client에서 시작된다면) 내부 테스터의 hosts 파일을 수정하여 일부 사용자만 신규 버전에 접근하도록 할 수 있다 기존의 인프라 구성 물리 서버 한대에 아파치 httpd (web서버) 1대 + 톰캣 WAS 2대가 배포되어 있으며 2대 모두 트래픽을 받고 있음 어떤 방식을 적용할 것인가 (+ 기준) 운영중인 서비스들에 적용하는것이기 때문에 제 1 전제는 서비스의 퍼포먼스에 영향을 주지..
어제 '혹시 빌드 배포 장비 용량이 꽉 찼나요..?' 라는 연락을 받았다. 해결 과정도 심플하고, 글로 정리할것도 많지 않아서 블로그 첫 글로 남겨보려 한다. 1. 우선 용량을 찍어보자 $df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 63G 0 63G 0% /dev tmpfs 63G 0 63G 0% /dev/shm tmpfs 63G 1.2M 63G 1% /run tmpfs 63G 0 63G 0% /sys/fs/cgroup /dev/nvme0n1p1 10G 5.6G 4.5G 56% / /dev/nvme2n1 50G 52M 47G 1% /app_log /dev/nvme1n1 9.8G 9.2G 3.7M 100% /usr_home /dev/nvme3n1 ..