고독한 IT 세상

봉이의 일상 - 12/14

모모토 — Sat, 14 Dec 2024 17:55:17 +0900

오늘은 토요일!

토요일은 항상 기분이 좋다 한주 휴일의 시작이기때문일까? 몽이를 만나는 날이기 때문이다 ㅎㅎ

하지만 .. 오늘은 몽이가 친구들을 만나는 날이라 혼자만의 시간을 보내야만 했다.

마침 나는 오늘 포켓몬고 이벤트를 하는날이라 오후에 잠깐 나갔다 오기로했다.

전설의 포켓몬을 잔뜩 잡을 수 있는 이벤트가 열리고 있길래 산책할겸 나갔다왔다. 은평구청이 포켓몬 명소로 아주 유명하다길래 방문해보았는데 세상에나 아래와 같이 엄청 많은 체육관이 있었다.

오늘은 몽이가 없는 관계로 내가 가진 다른계정을 가지고 전설의 포켓몬을 잡으러 갔다. 몽이랑 같이 즐기고 싶었지만 아마 추워서 같이하기는 힘들었을거다. 나도 추워서 카페로 피신했다 ....

포켓몬고를 즐기는 다양한 사람들

카페에 가는길에 포켓몬고를 즐기는 귀여운 친구들을 발견했다. 나도 어릴때 포켓몬고를 했다면 저렇게 즐겁게 게임을 했을까? ㅎㅎ 물론 나는 지금도 눈에 불을켜고 잡는다.

카페에 들어가니 역시나 포켓몬의 명소답게 많은 사람들이 포켓몬고를 즐기고 있었다. 그중에 .. 핸드폰 4개를 가지고 게임하시던분을 발견! 나보다 포켓몬고에 진심인 사람들이 정말 많다.

엄청 많은 전설의 포켓몬 '네크로즈마'를 잡았다. 겨우 색이다른 네크로즈마 두마리를 잡았다!

내가 사용한 색이 다른 네크로즈마와 일반 네크로즈마 , 마침 오늘 탄핵안 투표가 있다고 들었는데 국민의힘과 민주당의 대립을 보는 색매치가 재미있다.

오지않는 몽이의 연락을 기다리며 집에 가는길에 이마트를 들러 몸을 녹이면서 크리스마스를 맞이해서 부모님들과 장난감을 보러 온 아이들을 구경했다.

그리고 나도 내 사심을 채우로 장난감 코너에 진입 ㅎㅎ 내가 가장 좋아하는 포켓몬인 레쿠자와 뮤 프라모델을 발견했다.

남자의 DNA에는 드래곤을 보면 가슴이 뛰는 유전자가 있는것이 분명하다. 레쿠자는 정말 멋있는 포켓몬이다.

오늘 하루 간만에 걷기도 많이 걷구 몽이가 약속이 있어서 못 만나는날에 내가 뭘 하는지 일기로 보여주고싶어서 쓴 봉로그 완성~! 내일은 몽이와 데이트하는날!

뿅

봉이의 일상 - 12/01

모모토 — Tue, 10 Dec 2024 21:56:26 +0900

상견례 다음날 맞는 행복한 아침을 알려주는 송도 바다 , 간밤에 몽이와 산책도 하고 신혼 예행연습처럼 서로를 꼬옥 껴안고 잠에 들었다. 전날 긴장이 모두 풀리면서 너무나도 행복하고 편안하게 잘 잤다. 성공적인 상견례 후에 몽이와 사랑가득한 밤을 보내니 이보다 더 큰 행복이 있나 싶은 생각이 들었다. 아버님께서 5번넘게 강조한 행복한 삶에 대하여 평생의 숙제로 등에 업고 열심히 살아가야겠다고 바다를 보며 다짐했었다

몽이와 아침부터 티격태격 했던 국밥집을 위한 여정 부산의 버스는 유난히 정겨운 듯 하다.

데이트코스에 있어선 상당히 J인 몽이는 은근히 P적인 기질로 여유로운 봉이가 가끔 불만일때가 있는 것 같았다. 나는 부산의 어느 골목도 몽이와 함께있으면 그자체로 행복하지만 부산의 더 좋은곳을 보여주고싶은 몽이는 마음이 급했나보다 , 그때도 말했지만 다시 한 번 몽이의 예쁜 마음에 고맙다

몽이와 인터넷 서칭으로 찾은 부평깡통시장의 밀양집 돼지국밥을 먹으러 왔다.

내가 부산에 오기전 정말 부산의 돼지국밥을 먹고싶다고 노래를 불러서 몽이가 같이 와주었다 ㅎㅎ 부산 특유의 돼지국밥에 정구지를 듬뿍넣어서 속을 든든하게 채우고 싶었던 것 같다. 나는 부산에 와본적이 스무살적 말고는 없는데 부산 유투브를 많이봐서 그런지 뭔가 내적방문감(?)이 있었던 것 같다 이번엔 나도 정말 부산사람처럼 국밥을 먹어보겠어!

역시나 부산의 명물 국밥집중 하나여서 그런지 대기줄이 많았다. 우리처럼 처음 온 어머니 손님들이 친근하게 말을 거셔서 대화도 나누었다 ㅎㅎ 부산 로컬사람처럼 보이고싶어 몽이한테 부산 사투리 긴급강의를 들었는데 서울에서 왔다고 실토했다 ‍♀️

대망의 밀양집 국밥...!

문득 국밥은 국에 밥이 말아져나오는거구나..! 하고 국밥에 대한 재정의와 함께 국밥을 면밀히 살펴보았다.

듬뿍 들어간 돼지머리고기와 양념장 마늘 한숟갈 그리고 진해보이는 국물! 첫입은 맛이 심심했다 간은 정구지와 소금 새우젓등으로 알아서 맞춰 먹어야한다 국물은 심심한 느낌이었지만 그래도 돼지국밥의 깊은 맛이 있었다 재미있게도 밥알은 토렴을 해서 그런지 밥을 먹으니 오히려 간이 잘 맞고 맛있었던 기억이다 ㅎㅎ

서울에서는 보통 매운 얼큰이 국밥을 자주먹어서 그런지 심심하게 느껴지면서도 역시 국밥을 먹으니 속이 든든하면서 맛있게 먹었다.

봉이의 생애최초 돼지국밥 점수는~

⭐️⭐️⭐️⭐️

5점만점에 4점이다 ㅎㅎ 나는 너무 맛있게 먹었다 국밥은 어지간해선 보통은 간다! 그리고 김치가 맛있었다 ☺️

BIFF거리였었나..? 자갈치 시장을 가던길이었다 아침 비슷한 점심을 먹고 부산에서 잔뜩 군것질을 했다 ㅎㅎ 우리가 뭘 먹었는지 사진도 다 찍어둘 걸 하는 아쉬움이 남는다.

몽이가 그렇게 먹고싶어하고 나한테도 소개하고싶다던 물떡도 먹었다 오뎅국물에 푹 절여진 가래떡의 심감이 참 재미있고 은근 맛있었다 ㅎㅎ 봉몽하우스의 오뎅탕엔 떡도 넣어야겠

부산에서의 하루는 너무나도 짧기도했고 기차시간이 애매해서 뭘할지 고민하다가 크루즈를 타기로했다.

나는 정말 해본게 많이 없다는 생각이 들었다 크루즈도 처음 타는거라 부산바다를 눈에 담기 위해서 크루즈에 몸을 실었다.

크루즈의 첫 소감은 부산의 고령화가 얼마나 심각해졌는지 알 수 있었고 , 어머니 아버지들의 플레이 그라운드중 한곳이 바로 자갈치 크루즈였구나 싶었다. 오히려 이분들에게 우리가 방해가 아니었나 생각이 들었을 정도였다..

부산의 바다는 참으로 아름답다 .. 간만에 바다를 많이봐서 속이 뻥 뚫리는 기분이었다

바다도 좋지만 옆에 몽이가 있어서 더 행복했다.

즐겁게 바다를 보고있는 여자친구의 뒷모습을 보면 지켜주고싶은 생각이 든다.

일을 열심히 하루하루를 성실하게 살아야하는 이유는 모두 나의 아내에게 있다 이젠

행복한 부산여행의 마무리는 우리 몽이가 너무나도 아름답게 나온 부산역에서의 한컷으로 마무리

정말 사진 찍어주신 부산 어머니 너무 감사합니다 (우리 몽이가 세젤예로 나와서 기쁜 투샷이다 )

우리가 정말 양가에 부부로써 발돋움하기위한 가장 중요하고 떨렸던 첫 관문을 성공적으로 마쳤다는 기분에 뿌듯함과 행복한 책임감을 가득 안고 서울로 돌아왔다.

우리 앞으로 더 사랑하고 아끼고살자

봉이의 일상 - 11/30

모모토 — Sun, 8 Dec 2024 10:12:33 +0900

11월 30일 대망의 상견례 아침 떨리기도 했지만 떨리지 않았다.
인생에서 처음이었던 순간들을 떠올려보면 , 수능, 첫회사 입사, 새로운 곳으로의 여행 수 많은 처음이 있었지만 모두 다 연습이 있었고 어떻게든 무슨 수를 써서라도 잘 해내면 된다는 생각에 연습한대로 나만 잘하면 되었기에 , 그것이 잘 안될까봐 걱정하는 마음에 긴장이 왔다면

여자친구의 부모님을 뵙는 건 차원이 다른 문제였다. 서로 다른 강이 만나 하나의 물결을 이루는 자리라고 생각이 들었다. 그래서 부디 오늘 그 물살이 부드러웠으면 하는 마음과 한 치 앞도 예상안되는 상견례 자리로 인해 떨리다가도 있는 그대로의 나를 보여주면 된다며 스스로 떨림을 가라앉히는 반복이 진행되었다.

서울역 , 모든 것의 출발 같은 곳 같다.
나는 항상 서울역에 도착하면 사진을 찍는 거 같다.
이 여행의 시작점이랄까?

긴장도 식후경 , 일찍 일어나 너무 떨었는지 배가 고팠다.
몽이와 커피, 토스트를 사서 기차에 올랐다 개인적으로 기차에서 먹는 간식이 참 좋다 기차여행에서 빼놓을 수 없는 하나의 장르랄까? 몽이가 부산에 내려갈때 바래다 줬던 기억이 있는데 같이가지못해 기분이 이상했었다. 근데 이젠 부산에 내려갈 일이 있다면 항상 함께 내려 갈 생각에 정말 가족이 된 기분이었다

부산에 도착하고 상견례를 마쳤다.
매우 기다리던 시간이 쏜살같이 지나가고 그 후에야 내가 부산에 있음을 실감했다. 상견례를 마치고 몽이가 데려와 준 부산 송도바다

처음뵙는 어머님 아버님 처형과 형님 그리고 귀여운 소민양☺️
정말 말도 많이하고 자신있었는데 너무 어렵고 몸이 마음과 싱크가 맞지않았다. 어휘도 부적절하게 쓴 것 같구 아쉬움이 많았지만 아버님이 문서방이라고 하시는 걸 듣고는 마음이 많이 놓였다

아버님을 뵈니까 아빠의 빈자리가 쓰라린 느낌이 들었다. 아버님한테서 아빠와 닮은 점이 많이 보였기 때문이다. 글라스에 소주를 드시는 모습 과묵하지만 칭찬에 속절없이 무너지는 모습 정말 오랜만에 보는 모습이어서 그랬을까

정신없이 아버님과 이야기하는 나를 따뜻하게 감싸안아주신 어머님도 나중에가선 문득 생각이나서 죄송했다 피부가 너무 고우셔서 다음엔 설화수 말고 더 맛있는 먹을거리 선물을 드리겠다고 말씀드렸다

몽이가 예약해준 오션뷰 호텔과 어머님이 맛난거 사먹으라고 용돈을 챙겨주셔서 장어도 먹었다 그날 부산에는 바다가 하나 더 생겼다. 봉이가 눈물로 만든 감동의 바다
열심히 돈 모아서 2년뒤엔 동동이와 함께 넓은 집으로 이사를 갈테야!!

이튿날 부산여행 이야기는 다음 포스팅에서⭐️

봉이의 일상 - 11월 9-10일

모모토 — Tue, 26 Nov 2024 22:22:41 +0900

11월 9일 봉몽의 대망의 상견례..!
그날의 사진은 아래 식당입구밖에 없다… 그만큼 정신없었고 아래 사진도 그나마 가족들에게 주차위치를 알리기 위해 찍어놓았다.

여자친구가 가족들을 위해 고심끝에 예약을 한 곳 색동저고리 이름이 뭔가 정겹고 귀여웠다. 우리 가족에게 색동저고리를 입은 귀여운 아이가 달려와 행복을 전달하고 가는 느낌이 들었다.

처음부터 모든것이 순조롭고 기분 좋은 일들만 가득하면 얼마나 행복할까 하지만 그렇지않더라도 그 이후에 어떻게 해야할지가 나는 더 중요하다고 생각했다.

처음 상견례를 하며 ,비록 우리 가족과 여자친구만 만난 자리이지만, '남'이 만나 '하나의 가족'으로 되기 위하여선 물맞댐이 필요하다고 생각이 들었다. 아무리 상대를 위한 배려라 하더라도 서로를 모르는 상황이기에 그 과정에서 오해도 서운함도 생길 수 있다는 걸 깨달았던 거 같다. 아마 그 사이에서 가장 중요한 건 바로 중간의 매개체인 나의 역할이지 않았나싶다.

그래도 우리 가족은 여자친구를 진심으로 환영하고 아끼기에 나의 역할은 그저 진심을 전해주는것 뿐이었고 나의 미래의 아내의 마음을 이해하고 어루만져주는 것이라고 생각했다. 나는 여자친구를 사랑하니까 가족과의 친밀도는 시간이 해결해주겠지 생각한다 진인사대천명

앞으로 나에게 주어진 숙제, 좋은 남편, 좋은 아들 동생 그리고 좋은 아빠..

상견례가 끝난 다음날 우리는 관악구로 발걸음을 향해 새로운 보금자리를 찾아 떠났다. 새로운 동네는 봉천역 근처!

봉천역 근처는 시장도 있고 주변 분위기가 생각보다 정겨워서 이 근처에 살면 나쁘지않겠다는 생각이 들었다.

이날은 근처의 부동산을 참 많이 돌아다닌거같다. 두번째 부동산 탐방기였던것으로 기억하는데 점점 현실을 깨달아가면서 조금은 좌절한 나를 여자친구가 기운을 복돋아 주었다. 행복이 대수냐 조금 시무룩해진 나를 부여잡고 아이스크림을 먹자고 조르는 몽이를 보고있자면 나는 그냥 다음날 출근하여 열심히 기쁜 마음으로 일하고 행복하게 같이 살 궁리를 하면 되는것이다. 이젠 나를 위해서도지만 사랑하는 사람을 위해서 더 열심히 기쁜 마음으로 하루하루 알차게 살아야겠다는 행복한 다짐을 하는 요즘이다.

지나가다 베르사유의 정원처럼 정리된 플라타너스를 보면서도 나는 행복함을 느낄 수 있게 되었다. 언제나 든든하게 나의 팔을 잡아주는 사람이 있어서 그런걸까? 유독 올해의 가을은 길고 따뜻한 느낌이다.

인생은 선택으로 가득 차 있다고 한다. 집안에서 아무것도 안하는 것 그 자체도 본인의 선택이다. 나는 내 인생의 선장으로써 언제나 나의 앞길을 선택해왔고 오늘이 있기까지 나의 수많은 셀 수 없는 선택들이 지금 이 순간에 도달하게 만들었다. 한 번 이라도 다른 선택을 했다면 이 플라타너스 아래에서 나의 팔을 부여잡는 몽이가 있었을까?

what if ? '만약에'는 중요하지 않다 지금 나의 옆에있는 내 사람만 사랑하기에도 시간이 부족하다. 앞으로도 몽이와 함께 행복한 나날을 위해서 정진 또 정진이다!

이날 봉천동에 들렀던 메인 이유중 하나인 봉이돈까스를 먹으러 왔다. 돈까스가 가성비좋고 정말 맛있었다. 봉천동 살게된다면 종종 몽이랑 들르고싶은 맛집이다 ㅎㅎ

과연~ 우리는 봉이돈까스의 단골 고객이 될 수 있을까?

앞으로 봉몽의 집찾기 여정은 계속된다!

봉이의 일상 - 11월 3일

모모토 — Sat, 16 Nov 2024 22:58:16 +0900

11월 3일에 여자친구랑 우리가 가장 좋아하고 뜻깊은 장소인 부암동에 다녀왔다.

이날은 같이 커플 잠바를 입었다 ㅎㅎ 하나 둘 커플아이템이 늘어나는게 재미있고 뿌듯하다.

얼른 커플템을 쭈루룩 맞춰 나가고싶다.

여자친구 덕분에 입문한 필름카메라 그리구 지금은 내가 더 많이 찍는다 ㅎㅎ

을지로에서 여자친구와 처음으로 산 롤라이 자동카메라는 현재 기능에 문제가 있어 휴식중이고 그 빈자리를 채워주고있는 목측카메라 롤라이 35s , 엘리자베스 카메라로 유명한 귀엽고 성능좋고 마니아층이 있는 카메라이다.

디지털이 아니다보니 보수만 잘해준다면 내 자식에게 물려줘도 좋은 카메라 , 여자친구를 가장 많이 담고있는중!

같이 가을의 문턱을 넘어가는 느낌이 드는 부암동의 가을뷰는 정말 서울의 보물이다.

봄에도 여름에도 겨울에도 이 구도로 보는 서울은 참 좋다.

내가 좋아하는 걸 좋아하는 여자친구와 부암동에 올때마다 참 좋은 기억을 많이 만들고 간다.

부암동에 새로 생긴 카페에 들렀는데 지금도 그때의 날씨 바람 온도가 몸에 저장된 것 같다.

그 순간이 너무나도 좋으면 단순히 기억뿐 아니라 감각도 되살아나는 기분이 든다.

지난 1년간은 그런 시간이 너무 많아 기억하지 못 할 때는 나의 노화로 인한 기억력을 한탄한다.

참고로 이 사진은 여자친구를 위하여 내가 고심해서 찍었지만 현재 모종의 이유로 내가 쓰게되었다.

참으로 인생은 모르는 것 ㅎㅎ

여자친구의 귀여운 손 ㅎㅎ 언제나 우리가 카페에 들르면 나는 아메리카노 여자친구는 그때그때 마시고싶은 음료를 마신다. 카페의 메뉴를 보고있자면 나는 언제나 우직하게 아메리카노 다채로운 메뉴를 그때그때 고르는 여자친구는 팔색조같은 느낌이라 괜시리 커피와 블루베리 스무디 사진에 웃음이 나온다.

지나가다 고양이 , 뭔짓을 해도 혼나지도 맞지도 않고 오히려 귀여움을 사는 저 존재가 가끔은 부럽기도 하지만 나는 인간이길 추구한다. 마음이 약해져서 드는 생각일 것이야 정진 또 정진!

가끔 여자친구가 고양이를 맞딱드리면 고양이 소리를 내곤하는데 정말 똑같아서 고양이처럼 보인다. 너무 귀엽지만 정말 속에 고양이가 들어있는 건 아닐까?

너무 이쁜 은행나무 길

여자친구와 처음 만난날 게의 수렴진화 이야기를 하면서 은행나무 이야기도 나눴던 기억이 있다. 나의 이야기를 잘 귀담아 듣는 사람이라 이런 저런 이야기를 해주곤 하는데 요즘 내가 철학 이야기를 하면 살며시 도망간다.

높고 넓은 어떤 나무 이날 찍은 사진중 가장 마음에 드는 나무사진이다.

저 높이 솟은 나무를 동경한다. 왜 동경하는지는 나도 잘 모르겠지만 이 마음이 변하지않길 바라는 것 같다 스스로.

이날은 참 운이 좋다. 서울에서 정말 보기힘든 벌새를 찍었는데 여자친구는 벌새를 모르는 것 같았다.

정말 희귀한 새라서 얼른 찍고 여자친구에게 보여주었지만 여자친구의 반응은 '??' 이런 반응이라서 아 언제 한 번 벌새 특집으로 이야기를 해줘야겠다는 생각을 했다. 곤충이 아니라 새야!

여자친구가 먹고싶어했던 노랑통닭 신메뉴인 갈릭인더딥 치킨을 먹었다. 어쩐일로 잘 마시지않는 맥주를 시켜서 나와 같이 마셔줘서 내심 고마웠고 예뻤다 ㅎㅎ 나는 아무거나 잘 먹기때문에 여자친구가 먹고싶은걸 먹는 순간이 나는 참 기쁘고 뿌듯하고 그렇다. 노랑통닭을 먹고싶어하는 그녀가 얼마나 귀엽고 쓰담쓰담하고싶던지 앞으로도 먹고싶은게 있으면 자주자주 말해주면 좋겠다.

DBA 의 컴퓨터 공부 - write throuth , write back 그리고 Postgres

모모토 — Sun, 20 Oct 2024 22:18:52 +0900

기존의 MCU가 아닌 리눅스 기준으로 write throuth , write back 을 정리해보자 차이라면 아마도 디스크냐 메모리에 기입이냐 차이가 아닐지싶다.

write-through 방식은 캐시 데이터가 변경될 때 즉시 디스크에도 기록하는 방식이다. 성능은 낮지만, 데이터 일관성과 안정성을 보장하는 데 유리하다. 예를 들어, 매우 중요한 데이터를 다루는 시스템에서 write-through가 사용될 수 있다.

리눅스에서는 데이터를 캐시나 버퍼에 먼저 저장한 후, 일정 시점에 디스크로 기록하는 write-back 방식을 많이 사용한다. 이는 성능을 극대화하기 위한 것이며, 시스템 충돌이나 전원 장애 시 데이터 손실의 위험이 있을 수 있다. 그러나 데이터베이스나 파일 시스템에서 로그나 WAL을 사용해 데이터 복구를 보장하는 추가적인 안전 장치를 마련해 둔다.

PostgreSQL에서 write-back과 write-through 방식은 데이터 저장 및 처리에 있어 중요한 역할을 한다. 이 두 개념은 PostgreSQL의 데이터베이스 성능과 안전성 간의 균형을 유지하는 데 사용된다. 각각의 개념과 PostgreSQL에서의 활용 방식을 설명해보겠다.

1. Write-back

PostgreSQL에서 write-back은 데이터를 먼저 메모리(Buffer Pool)에 기록한 후, 나중에 디스크에 기록하는 방식이다. 즉, 데이터가 즉시 디스크에 쓰이지 않고 메모리에 일시적으로 저장되며, 적절한 시점에 디스크로 플러시된다. 이 시점은 시스템에 따라 다르며, checkpoint나 background writer와 같은 메커니즘을 통해 이루어진다.

PostgreSQL은 성능을 높이기 위해 먼저 데이터를 메모리에서 처리하고, 디스크 I/O 작업을 지연시킨다. 데이터가 메모리에 저장된 상태로 남아 있지만, 실제 디스크에 쓰이는 시점은 나중에 발생한다. 이 방식은 디스크 I/O 병목을 줄이고 성능을 극대화하는 데 큰 도움을 준다. 특히, 대량의 트랜잭션을 처리할 때 디스크에 자주 기록하지 않음으로써 효율적으로 시스템 자원을 관리할 수 있다.

이 방식을 보완하기 위해 PostgreSQL은 WAL(Write-Ahead Logging) 시스템을 사용하여 데이터가 실제로 디스크에 기록되기 전에 로그 파일에 트랜잭션 내역을 기록한다. 시스템이 충돌하거나 장애가 발생했을 때, WAL 로그를 통해 복구 작업을 진행할 수 있기 때문에, 데이터 손실을 방지할 수 있다.

그러나 write-back 방식은 데이터가 메모리에만 존재하는 동안 장애가 발생하면 데이터 유실 가능성이 있다. 이런 위험을 줄이기 위해 PostgreSQL은 일정한 주기로 checkpoint를 수행하여 메모리에 있는 데이터를 안전하게 디스크로 기록한다.

2. Write-through

Write-through 방식은 데이터를 메모리에 기록하는 동시에 디스크에도 즉시 기록하는 방식이다. 이 방법은 PostgreSQL에서 기본적인 데이터 쓰기 방식은 아니지만, WAL 로그를 처리할 때 유사한 방식으로 동작한다. 트랜잭션이 커밋될 때, WAL 로그는 디스크에 즉시 기록되므로 장애가 발생해도 트랜잭션 로그를 복구할 수 있다.

PostgreSQL에서 `fsync_writethrough` 옵션을 사용하면, WAL 로그는 디스크의 캐시를 사용하지 않고 디스크에 직접 기록된다. 이 방식은 데이터의 안전성을 극대화하지만, 성능 저하의 단점이 있다. 디스크 캐시를 우회하기 때문에 디스크 I/O 작업이 자주 발생하고, 이로 인해 성능이 떨어질 수 있다.

Write-through 방식은 데이터 일관성을 보장하며, 트랜잭션이 커밋될 때마다 즉시 디스크에 반영되기 때문에, 데이터 유실 가능성을 최소화한다. 그러나 성능이 저하될 가능성이 있어 성능보다 데이터 안전성을 우선시하는 환경에서 주로 사용된다.

PostgreSQL에서의 활용

PostgreSQL은 기본적으로 write-back 방식을 사용하여 성능을 최적화한다. 데이터가 메모리에 먼저 기록되고, 나중에 디스크로 기록되기 때문에 디스크 I/O 부담이 적어지고, 데이터 처리 속도가 매우 빠르다. 하지만 데이터의 안전성도 중요하기 때문에, 트랜잭션 로그는 write-through 방식으로 WAL에 즉시 기록되며, 이를 통해 장애가 발생해도 데이터를 안전하게 복구할 수 있다.

결론적으로, PostgreSQL은 write-back 방식을 통해 성능을 높이고, write-through 방식을 WAL 로그에 적용하여 데이터의 안전성을 확보하는 전략을 사용한다.

DBA 의 컴퓨터 공부 - 엔지니어로써 알아야 할 LINUX Memory (free -h)

모모토 — Sun, 20 Oct 2024 18:03:30 +0900

Postgres 공부를 하면서 그리고 datapage , memory에 관한 공부를 진행하면서 더욱 근본적인 컴퓨터에 대해서 공부의 필요성을 느꼈다. 어쩌면 컴퓨터에서 일어나는 일이기에 당연한 것이기도하다. 컴공과 출신이 아닌 내가 지금이라도 한 번 정리해야하는건 필연적인 과정이다.

리눅스에서 메모리는 시스템 성능에 매우 중요한 역할을 한다. 메모리 자원의 적절한 관리는 시스템 안정성과 성능을 유지하는 데 필수적이다. `free -h` 명령어는 시스템의 메모리 사용 상태를 확인하는 데 유용한 도구로, 사람이 읽기 쉽게 메모리 사용량을 보여준다. 여기서는 `free -h` 명령어의 출력 항목을 기반으로 리눅스 메모리 관리에 대해 설명한다.

1. Mem (물리적 메모리) 섹션

- total (전체 메모리)

시스템에 설치된 물리적 메모리(RAM)의 총량을 의미한다. 이 값은 시스템이 사용할 수 있는 전체 물리적 메모리 용량이다. 예를 들어, 16GB의 물리적 메모리가 장착된 시스템에서는 total이 16GB로 표시된다.

- used (사용 중인 메모리)

현재 사용되고 있는 메모리의 양을 의미한다. 이 값에는 실제로 프로세스가 사용하고 있는 메모리뿐만 아니라 버퍼와 캐시로 사용 중인 메모리도 포함된다. 이는 메모리가 프로세스에 의해 할당되었거나 시스템 성능 최적화를 위해 일시적으로 저장되는 데이터를 포함한다.

- free (사용 가능한 메모리)

아무 작업에도 사용되지 않고 남아 있는 물리적 메모리이다. 그러나 리눅스는 메모리의 효율적인 활용을 위해 가능한 한 많은 메모리를 캐시로 사용하려 하기 때문에, free 값이 적더라도 시스템이 메모리 부족 상태인 것은 아니다. 필요한 경우, 캐시 메모리가 해제되어 다른 프로세스에서 사용할 수 있다.

- shared (공유 메모리)

여러 프로세스 간에 공유되고 있는 메모리의 양을 의미한다. 주로 tmpfs나 IPC(프로세스 간 통신)에서 공유 메모리로 사용된다. 이 메모리는 여러 프로세스가 데이터를 공유할 때 활용된다.

- buff/cache (버퍼/캐시 메모리)

버퍼와 캐시로 사용 중인 메모리의 합계를 나타낸다. 이 값은 시스템 성능을 최적화하기 위해 메모리 자원을 효율적으로 사용 중인 메모리 영역을 포함하며, 필요 시 다른 프로세스에 할당될 수 있다.

***1. 버퍼(Buffer)는 주로 디스크 I/O 작업을 최적화하기 위해 사용된다. 데이터를 디스크로 쓰기 전에 일시적으로 메모리에 저장해 두는 역할을 한다. 데이터를 디스크에 직접 쓰는 대신, 먼저 버퍼에 저장함으로써 여러 개의 작은 쓰기 작업을 하나의 큰 작업으로 묶어 디스크 쓰기 성능을 높인다. 또한, 디스크에서 데이터를 읽을 때도 마찬가지로 버퍼에 데이터를 저장한 후 처리한다.

***2. 캐시(Cache)는 자주 사용되는 데이터나 파일을 메모리에 저장하여, 디스크에 다시 접근하지 않고 빠르게 데이터를 읽을 수 있도록 한다. 캐시는 파일 시스템이나 프로그램이 자주 접근하는 데이터를 저장해 두기 때문에 성능을 크게 향상시킬 수 있다. 예를 들어, 웹 서버가 자주 요청받는 파일을 캐시로 관리하면 디스크 접근 없이 빠르게 파일을 제공할 수 있다.

- available (사용 가능한 메모리)

시스템에서 실제로 사용 가능한 메모리의 양을 나타낸다. available은 캐시 메모리까지 고려한 값으로, 프로세스가 추가적인 메모리를 요청할 때 시스템이 제공할 수 있는 메모리 자원이다. 캐시 메모리가 필요시 해제되어 재사용될 수 있기 때문에, available 값이 free 값보다 클 수 있다.

2. Swap (스왑 메모리) 섹션

- total (스왑 총량)

시스템에서 사용할 수 있는 스왑 공간의 총량을 나타낸다. 스왑은 물리적 메모리가 부족할 때, 디스크를 사용하여 메모리처럼 활용하는 공간이다. 스왑은 성능 저하를 초래할 수 있지만, 물리적 메모리 부족 시에는 시스템이 스왑을 사용해 안정성을 유지한다.

- used (사용 중인 스왑 메모리)

현재 사용되고 있는 스왑 공간의 양을 의미한다. 물리적 메모리가 부족할 때, 사용하지 않는 메모리 페이지가 스왑으로 옮겨지며, 스왑에 저장된 데이터는 물리적 메모리보다 느리게 접근된다. 스왑이 많이 사용되는 경우, 시스템 성능이 저하될 수 있다.

- free (사용 가능한 스왑 메모리)

남아 있는 스왑 공간을 나타낸다. 스왑 공간이 충분히 남아 있으면, 물리적 메모리가 부족할 때 시스템이 안정적으로 동작할 수 있다.

리눅스 메모리 관리 동작 방식

리눅스는 메모리를 매우 효율적으로 관리한다. 가능한 많은 메모리를 버퍼와 캐시로 사용하여 시스템 성능을 최적화한다. 그러나 새로운 프로세스가 메모리를 요구하면, 캐시 메모리나 버퍼에 사용 중인 메모리를 해제하여 해당 프로세스에 할당한다. 이를 통해 시스템은 메모리를 낭비하지 않고, 필요에 따라 동적으로 할당할 수 있는 유연성을 유지한다.

버퍼와 캐시로 사용되는 메모리는 언제든지 다른 용도로 사용할 수 있도록 관리되며, 이는 시스템 성능을 향상시키는 데 중요한 역할을 한다. `free -h` 명령어에서 free 값이 적다고 해서 시스템에 메모리가 부족한 것은 아니다. available 값을 참고해야 실제로 사용할 수 있는 메모리를 파악할 수 있다.

결론

리눅스 메모리 관리에서 `free -h` 명령어는 시스템 메모리의 상태를 쉽게 이해할 수 있도록 돕는다. 이를 통해 엔지니어는 물리적 메모리와 스왑 메모리의 사용 상태를 파악하고, 버퍼/캐시 메모리와 available 메모리를 고려해 시스템이 실제로 얼마나 많은 메모리를 사용할 수 있는지 정확하게 판단할 수 있다. 이 정보를 바탕으로 시스템의 성능 최적화와 메모리 관리에 필요한 조치를 취할 수 있다.

Postgres - vacuum .. 은 메모리를 청소하지 않아

모모토 — Tue, 15 Oct 2024 01:08:07 +0900

postgres 에서 MVCC(Multi Version Concurrency Control) 을 위해서 독특한 기능이 존재하는데 바로 VACUUM이다.
그런데 필자도 그렇고 주변에 vacuum에 대해서 오해하는 경우가 더러 있는 것 같았다. vacuum이 메모리를 청소하는가?
아니다 vacuum 과 메모리 확보는 상관관계지 원인과 결과가 아니다.

24.1.2. Recovering Disk Space

In PostgreSQL, an UPDATE or DELETE of a row does not immediately remove the old version of the row. This approach is necessary to gain the benefits of multiversion concurrency control (MVCC, see Chapter 13): the row version must not be deleted while it is still potentially visible to other transactions. But eventually, an outdated or deleted row version is no longer of interest to any transaction. The space it occupies must then be reclaimed for reuse by new rows, to avoid unbounded growth of disk space requirements. This is done by running VACUUM.

https://www.postgresql.org/docs/current/routine-vacuuming.html

vacuum 은 disk에서 dead tuple 을 정리한다. 이 dead tuple 은 MVCC 동시성 제어를 위하여 생기는데 위 postgres 공식문서에서 확인 할 수 있듯이 UPDATE , DELETE 시에 기존의 tuple을 old version으로 남겨두고 UPDATE 일땐 새로운 tuple , new version , 로 복사한다. DELETE 라면 new version 없이 제거일 것 이다.

해당 record에 대한 select 요청이 온다면 DM 쿼리가 잡고있는 트랜잭션이 끝나고 commit 이 될 때까지는 old version 을 참조하게 된다. 이러한 원리로 MVCC를 유지할 수 있다. 이 모든 과정이 shared buffer 에서 이뤄진다.

수정이 발생하였으나 디스크에 기록되지않은 페이지를 Dirty page라 부르며 2가지 경우에 disk 에 기록이 된다. 하나는 check point 발생시 다른 하나는 버퍼 교체 알고리즘에 의해서 교체될 때이다.

update 된 tuple에 의해서 Dead tuple이 생긴 dirty page

check point로 인한 디스크 쓰기와 알고리즘에 의한 교체는 목적이 다르다. 플러시는 메모리의 수정된 데이터를 디스크로 단순히 저장하는 과정일 뿐, 데이터 구조 자체에는 변화를 주지 않으며 이 과정에서는 죽은 튜플도 여전히 디스크에 기록된다. 디스크에 기록된 페이지의 dead tuple은 vacuum에 의해서 청소가 되지만 memory와 동기화되지는 않는다. 정확히 이야기하자면 동기화는 일어나지만 vacuum 이 실행하는건 아니고 Postgres 자체의 캐시관리 시스템을 인하여 일어나지만 disk의 dead tuple을 제거한다고 무조건 동기화가 되지않고 메모리에는 남을 수 있다. 따라서 vacuum은 메모리와는 직접적으론 무관하며 disk에서 vacuum이 일어나도 버퍼에는 여전히 dead tuple이 존재하여 메모리를 점유 할 수 있다.

Vacuum의 역할에 대해서 GPT와 검증도중 혼동을 일으키는 AI를 바로 잡았다.

따라서 존재하는게 페이지 교체 알고리즘이다. postgres에서는 C언어로 구현된 모듈인 Buffer manager가 Clock-sweep 알고리즘을 사용하여 페이지 교체를 진행한다. 사용하지 않는 오래된 페이지를 디스크로 내려보내고 메모리를 비운다. 이 Clock sweep이 LRU와 비슷하다. 아래의 그림은 메모리에서 생성된 dead tuple이 vacuum에 의하여 제거되는 과정이다.

1. Clock Sweep에 의해서 사용이 적은 페이지가 디스크에 기록됨

2. buffer에 새로운 페이지가 교체됨으로써 메모리 확보

3. VACUUM이 disk의 dead tuple을 정리하여 디스크 공간 확보

INDEX에 대하여 .. 조금 더 깊은 이야기 (Postgres 와 datapage)

모모토 — Tue, 15 Oct 2024 01:05:54 +0900

INDEX란 .. 간단하게 이야기하면 하나의 테이블의 레코드와 그 레코드가 담긴 데이터 페이지의 매핑정보를 담아놓은 구조라고 볼 수 있다. 또한 랜덤 액세스는 인덱스가 제공하는 중요한 이점 중 하나이다.

PostgreSQL에서 인덱스는 테이블의 특정 컬럼 값과 해당 값이 저장된 위치 정보를 연결해, 쿼리를 효율적으로 실행할 수 있게 돕는다. 이 정보를 통해 데이터베이스는 테이블 전체를 탐색하지 않고도 필요한 데이터를 빠르게 찾아낼 수 있다.

인덱스의 역할

인덱스는 특정 컬럼의 값과 그 값이 저장된 데이터 페이지 번호와 페이지 내 위치(오프셋)를 연결한다. PostgreSQL에서는 이 정보를 TID(Tuple Identifier)라고 부르며, TID는 해당 데이터가 저장된 페이지 번호와 행의 위치(오프셋) 정보를 포함한다. 이를 통해 PostgreSQL은 테이블에서 데이터를 읽을 때 시퀀셜 스캔 대신 인덱스 스캔을 사용할 수 있으며, 필요한 데이터가 있는 정확한 위치를 빠르게 찾아낼 수 있다.

사실 페이지 자체도 논리적인 개념으로 디스크든 메모리든 어딘가 물리적 위치에 자리잡게된다. 이때 물리적인 위치는 랜덤엑세스하게되고 내가 찾아야하는 데이터가 담긴 페이지의 '논리적 페이지 번호(인덱스로 관리하기 위해 pg가 부여한)' 를 찾으면 해당 페이지를 Shared Buffers에 로딩하고 그 페이지 안에서 offset으로 레코드를 탐색하여 정보를 꺼낸다.

인덱스가 없다면, 데이터베이스는 테이블의 모든 행을 처음부터 끝까지 순차적으로 탐색해야 한다. 그러나 인덱스를 사용하면, 해당 컬럼의 값을 기준으로 데이터가 저장된 위치를 미리 알고 있어, 디스크에서 필요한 데이터 페이지로 바로 이동할 수 있다. 이로 인해 쿼리 실행 속도가 대폭 향상된다. (바로 이동이라는 표현이 과격할 순 있으나 어쨌든 풀스캔에 비해서이니 양해부탁드린다.)

인덱스는 메모리와 디스크 모두에 적용된다. 데이터베이스는 먼저 메모리인 Shared Buffers에 해당 페이지가 있는지 확인(이 과정에서도 랜덤엑세스)하고, 없으면 디스크에서 해당 페이지를 로드해 메모리로 가져온다. 페이지를 메모리로 로드한 후에는 오프셋을 통해 해당 페이지 내에서 데이터를 찾아낸다. 따라서 인덱스는 디스크에서 데이터를 로드할 때도, 메모리에서 데이터를 검색할 때도 성능을 최적화하는 중요한 도구이다. 따라서 인덱스는 필요한 데이터 페이지의 위치를 미리 알고 있으므로, 디스크 I/O(입출력) 비용을 크게 줄여준다.

B-트리 인덱스

PostgreSQL에서 가장 흔히 사용되는 인덱스 유형은 B-트리 인덱스이다. B-트리 인덱스는 컬럼의 값을 기준으로 데이터를 트리 구조로 정렬하고 저장하며, 검색할 때는 트리를 탐색하여 값을 빠르게 찾는다. 트리의 리프 노드에는 해당 값이 저장된 데이터 페이지 번호와 오프셋이 매핑되어 있어, 이를 통해 데이터베이스는 디스크에서 특정 페이지에 빠르게 접근할 수 있다.

출처 : https://medium.com/@egorponomarev/b-tree-index-in-postgresql-b4e3ac8ed92f

이 그림은 B-트리 구조에서 특정 값을 탐색하는 과정을 설명하는 예시이다. 여기에서 -6 값을 찾는 과정을 알아보자

1. 루트 노드에서 탐색 시작:

탐색은 항상 루트 노드에서 시작됩니다. 루트 노드에는 -15, 10, 25가 있다.
-6은 -15보다 크고, 10보다 작기 때문에, 루트 노드에서 -15와 10 사이의 자식 노드로 이동.

2. 첫 번째 중간 노드로 이동:

이제 -15와 1 사이의 자식 노드로 이동하게 됩니다. 이 중간 노드에는 -15, 1, 4가 있다.
-6은 -15보다 크고, 1보다 작기 때문에, -15와 1 사이의 자식 노드로 다시 이동

3. 리프 노드로 이동:

리프 노드에는 실제 데이터가 저장되어 있으며, 여기에서 -6 값을 찾는다.
그림에서 보면 -6은 리프 노드에 있는 데이터 중 하나이며, 해당 값을 찾게 된다.

전체 경로 요약:

루트 노드에서 -15와 10 사이의 자식 노드로 이동.
중간 노드에서 -15와 1 사이의 자식 노드로 이동.
리프 노드에서 -6 값을 찾아서 데이터에 접근.

이 과정을 통해 B-트리는 데이터를 효율적으로 탐색하며, 트리의 각 단계에서 범위에 따라 적절한 자식 노드로 이동하게 된다.

INDEX에 대하여, JOIN을 곁들인

모모토 — Sun, 13 Oct 2024 18:56:04 +0900

JOIN은 데이터베이스에서 여러 테이블을 결합해 데이터를 조회하는 기능이다.

테이블 간의 관계를 정의하고, 그 관계를 기반으로 필요한 데이터를 하나의 결과로 결합하는 역할을 한다.

예를 들어, 고객 정보와 주문 정보를 각각 다른 테이블에서 조회하고자 할 때, JOIN을 사용하면 두 테이블의 데이터를 결합하여 고객별 주문 내역을 조회할 수 있다.

JOIN은 여러 테이블을 동시에 처리해야 하므로, 테이블의 크기가 크거나 결합 조건이 복잡할 경우 성능에 부정적인 영향을 미칠 수 있다. 따라서, JOIN을 사용할 때는 성능을 최적화하기 위한 전략이 필요하다. 여기서 중요한 도구 중 하나가 바로 인덱스다.

Sequential Scan(Full Scan) & Index Scan ( Random access)

인덱스는 특정 데이터를 빠르게 찾기 위한 도구로, 테이블의 특정 컬럼에 대해 데이터를 정렬된 구조로 저장하여, 필요한 데이터를 빠르게 검색할 수 있게 한다. 인덱스가 없으면 데이터베이스는 테이블의 모든 행을 일일이 검색하는 시퀀셜 스캔을 해야 하지만, 인덱스를 사용하면 랜덤 액세스를 통해 원하는 데이터를 바로 찾아낼 수 있다. 특히, JOIN 연산에서는 인덱스를 적절히 사용하면 성능을 크게 향상시킬 수 있다.

인덱스는 B-트리(B-tree)와 같은 자료 구조로 구현되며, 이 구조를 통해 DB는 데이터를 빠르게 검색할 수 있다. B-트리는 데이터를 정렬된 상태로 유지하며, 범위 검색과 같은 작업에서도 매우 효율적이다. 예를 들어, `WHERE` 조건을 사용해 특정 범위의 데이터를 조회하거나, JOIN을 통해 여러 테이블을 결합할 때, 인덱스는 쿼리의 성능을 크게 향상시킨다.

정돈되어 있는 방 , 그렇지 않은 어지러진 방 어떤방에서 원하는 물건을 바로 찾을 수 있을까?

인덱스를 사용하면 랜덤 액세스를 통해 디스크에서 데이터를 빠르게 찾을 수 있다. 이는 대규모 데이터셋에서 중요한 성능 최적화 기법이다. 하지만 인덱스는 추가적인 저장 공간을 요구하며, INSERT, UPDATE, DELETE 작업 시에는 인덱스가 업데이트되므로 쓰기 성능에 약간의 부담을 줄 수 있다. 따라서, 모든 컬럼에 인덱스를 생성하는 것은 성능 저하를 초래할 수 있으며, 어떤 컬럼에 인덱스를 설정할지 신중하게 결정해야 한다. 방을 정돈하기 위해서 나의 에너지를 써서 정리하고 유지해야 한다. INDEX의 생성은 방을 하나 만들고 꾸준히 청소하고 정리해야 하는 것과 같다. 엔트로피 감소이다.

결론적으로, JOIN은 여러 테이블의 데이터를 결합하는 강력한 도구이지만, 성능 최적화를 위해서는 인덱스와 같은 기법을 적절히 사용해야 한다. 특히, 인덱스는 데이터베이스에서 데이터를 효율적으로 검색하고, JOIN 연산을 포함한 다양한 쿼리에서 성능을 향상시키는 중요한 역할을 한다.