일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- APM
- mysql 튜닝
- kotlin
- 정보처리기사 실기
- PETERICA
- kotlin coroutine
- 정보처리기사 실기 기출문제
- MySQL
- minikube
- CKA 기출문제
- Linux
- 코틀린 코루틴의 정석
- 공부
- AI
- Elasticsearch
- kotlin spring
- 기록으로 실력을 쌓자
- CKA
- 정보처리기사실기 기출문제
- CloudWatch
- Pinpoint
- AWS EKS
- Java
- Kubernetes
- 티스토리챌린지
- 오블완
- Spring
- aws
- kotlin querydsl
- IntelliJ
- Today
- Total
목록분류 전체보기 (781)
피터의 개발이야기
리눅스 시스템에서 메모리 사용량 확인 방법 간단하게 시스템 전체 메모리 확인하기 위해 free 명령어를 이용. 프로세스별 메모리를 확인하려면 ps 명령어를 이용한다. ps -eo user,pid,ppid,rss,size,vsize,pmem,pcpu,time,cmd --sort -rss | head -n 11 좀더 자세히 보려면 프로세스 아이디를 통해 알아볼 수 있다. cat /proc/16051/status
엔티티의 변수들은 테이블 컬럼과 매핑된다. @Getter @Setter @ToString @JsonNaming(PropertyNamingStrategy.SnakeCaseStrategy.class) public class UserEntity { // 고유키 private Long userId; // 페이데이 사용자 ID private Long paydayUserId; // 비밀번호 private String password; // 사용자명 private String name; // 이메일 private String email; // 전화번호 private String phone; } 하지만 비지니스 로직을 수행하기 위해 컬럼에 없는 변수가 발생하기도 한다. 예를 들어 회원가입 시에 패스워드 확인용 변수를 ..
리눅스에서 압축파일을 핸들링할 때에 꼭 기억이 나지 않아 검색을 하게 된다. 제일 많이 쓰는 tar tar.gz 명령어를 정리하였다. 1. tar 압축 풀기 --> tar -xvf 파일명.tar 2. tar로 압축하기 --> tar -cvf 파일명.tar 폴더명 3. tar.gz로 압축하기 --> tar -zcvf 파일명.tar.gz 폴더명 4. tar.gz 압축 풀기 --> tar -zxvf [파일명.tar.gz] 5. 구체적 옵션 설명 옵션 설명 -c tar로 묶기 -x tar를 풀기 -z gzip(gz)으로 압축 -f 파일 이름 지정 -v 작업 화면을 출력 -C 경로를 지정 -p 파일 권한 저장
Stream을 사용하면 늘 쓰는 것만 사용하게 된다. 나 같은 경우 filter를 주로 많이 사용하는데, fiter는 중간처리자이다. 곧, Stream을 반환하기에 최종 처리 단계를 더 거쳐야 한다. 특히 단순히 list 중에 값이 있는지만 알기 위해 간단한 방법이 있다. API는 최종 처리 단계 특정 조건을 만족하는 요소들을 얻을 수 있도록 세가지 매칭 메소드를 제공한다. allMatch() 모든 요소들이 주어진 조건을 만족하는지 조사, anyMatch() 모든 요소 중 한 개라도 조건에 만족하는지 조사, noneMatch() 주어진 조건에 모든 요소들이 안 맞는지 조사, allMatch() 사용 시 주의점이 있다. 리스트가 널일 경우 true를 반환한다. 자칫 버그처럼 보이지만 논리학에서 가정이 거짓..
초기의 인터넷은 단순하였다. 자바가 시작되고, 처음 서블릿이 만들어지면서 WEB은 세상에 나타났다. 자바 어플리케이션이다. 즉 Client - Server : 2tier 구성이다. 자바는 반응속도도 느리고 동시접속에 약하다. 개발자의 입장에서는 2tier가 편할 수 있다. 웹에서 사용자가 입력한 정보를 바로 디비에 저장한다. 하지만 서버정보다 노출이 되고 보안에 취약하다. Client - apach web - Tomcat Server: 3tier 구성을 하기 시작하였다. apach web은 여러 프로세스를 띄워 정적인 데이터를 빠르게 응답하였고, 동적인 데이터는 톰켓을 통해 처리하였다. 그래서 서버정보를 웹을 통해 숨길 수 있다. 서버를 프라이빗에 두게 되면서 보안적으로 더 유리해졌다. 그리고 웹을 두면..
시스템 로그 파일 모니터링을 위해 만들었던 쉡. 톰켓의 로그를 하루단위로 압축하여 저장하였다. 저장된 압축파일의 로그를 분석하여 에러가 있을 경우 에러의 종류와 발생 건수를 정리하여 보여주는 쉘. #!/bin/bash logFile=catalina if [ -z $1 ]; then chkDay=1 else chkDay=$1 fi echo "check Day : " $chkDay echo "" echo "----------------list of Log File -----------------" find ./ -type f -mtime -$chkDay -ls echo "" echo "----------------sorting ------------------" find ./ -type f -mtime -$..
Tomcat catalina.out 로그는 지속적으로 쌓여서 기가 단위로 커지는 경우가 있다. 간혹 용량 확인하지 않고 로그 확인을 위해 VI로 열게 되면, 시스템 메모리가 꽉차 시스템 장애가 발생하는 경우가 더러 있다. 내가 주로 쓰는 Tomcat catalina rotaion shell 이다. logBak.sh에 저장하고 특정 경로 위치만 바꾸어 사용하고 있다. crontab에 잡을 주어 매일 실행하도록 설정한다. #!/bin/bash #logs에 있는 catalina.out 파일을 분리하여 backup에 압축 저장한다. SRCDIR="/home/ubuntu/tomcat/logs" DESTDIR="/home/ubuntu/tomcat/logs/backup" DATE_WITH_TIME=`date "+%Y..
시스템을 운영하면서 데이터가 쌓이게 된다. 다량의 데이터 조회 속도를 높이기 위해 인덱스를 사용하지만, 테이블의 데이터가 많아지면 인덱스 자체의 물리적인 용량이 증가라한다. 인덱스 조차도 허용된 메모리를 넘는 어느 순간 그 테이블 조회 속도는 현저히 느려진다. 큰 테이블은 월별 혹은 일자별로 나누어 관리하는 것이 바람직하다. 내가 쓰고 있는 테이블별 용량 확인 쿼리이다. ############################################################ # 테이블별 용량 SELECT table_name, table_rows, round(data_length / (1024 * 1024 * 1024), 2) as 'DATA_SIZE(GB)', round(index_length / (..
내가 자주 사용하는 디비 모니터링 SQL문 정리 디비 부하 시 현재 문제가 되고 있는 프로세스와 SQL을 확인 할 수 있는 쿼리 ############################################################ # 디비 프로세스 확인 ############################################################ select # count(*) * from information_schema.processlist where 1 = 1 # and COMMAND = 'Sleep' and COMMAND != 'Sleep' and ID not in (847, 972) # and HOST like '172.31.21.139%' # and HOST like '1..
AWS(Amazon Web Services)란 남는 장사를 위해 탄생되었다. 자동차가 늘 최고 속력을 달리지 않지만 최고 속력을 내기 위해 엔진의 마력을 설정한다. 인터넷 인프라도 마찬가지로 늘어난 트래픽과 주문량을 감당하기 위해 규모를 키울 수 밖에 없다. 대부분의 인프라 자원들은 사용하지 않고 남게 되는데, 미국 기업인 아마존은 자신들이 구축한 온라인 쇼핑몰의 경험을 토대로 안정적으로 컴퓨팅, 데이터베이스, 저장공간, 네트워크 인프라를 누구나 쉽게 이용할 수 있도록 돈을 받고 서비스하게 되었다. 그들은 자신들의 쇼핑몰을 운영하면서 남는 인프라를 통해 남는 장사를 시작한 것이다. 이것이 AWS의 탄생이다. AWS를 쓰는 사람도 남는 장사이다. 누군가 IT아이템을 구상하고 초기에 인프라를 구축하자면 많은..