16GB 쓰는데 평소엔 조용하거든요. 그런데 컴포넌트가 여러 겹 물린 파일 한둘만 열면 활성 상태 보기에서 메모리 압력이 노랗게 뜨면서 스왑이 올라와요. 다른 파일은 멀쩡한데 그 파일만 그래서, 램이 부족한 건지 파일 구조 문제인지 아직 안 갈리더라고요. 비슷하게 특정 파일에서만 눌리는 분 계신지, 그럴 때 파일을 쪼개시는지 아니면 그냥 버티시는지 궁금합니다.
특정 파일 하나에서만 메모리 스왑 걸리는 거, 다들 그런가요?
10.29 08:45조회수 0댓글 8
활성 상태 보기에서 노랗게 뜨는 그 파일만 따로 떼서, 컴포넌트가 몇 겹으로 중첩됐는지부터 한번 세어보시는 걸 권해보고 싶어요. 저도 포폴 파일 중에 유독 한 개만 열면 팬이 돌면서 스왑이 치고 올라오는 게 있었거든요. 다른 파일은 더 무거운데도 멀쩡해서, 램 탓인 줄 알고 한참 애먼 데를 봤어요. 열어보니 같은 인스턴스를 수십 번 겹쳐놓고, 그 안에 또 오토레이아웃이 중첩돼 있더라고요. 저는 그걸 통째로 쪼개기보다, 반복되는 덩어리를 하나의 컴포넌트로 묶어서 참조로만 쓰게 바꿨더니 그 파일만 훨씬 조용해졌어요. 그러니까 꼭 램이 부족하다기보다, 그 파일 하나가 구조상 유난히 무겁게 쌓인 거일 수도 있겠더라고요. 쪼개기 전에 중첩 깊이부터 한 번 보시면 갈리는 지점이 보일지도 몰라요.
저는 영상 쪽이라 결이 좀 다를 수 있는데, 예전에 유독 한 컴포지션만 열면 활성 상태 보기가 노랗게 뜨던 적이 있었어요. 다른 건 멀쩡한데 그 파일만 그래서 저도 램 탓인가 싶었거든요. 근데 뜯어보니 같은 소스를 여기저기서 중첩으로 불러다 쓰면서 캐시가 그 파일에서만 왕창 쌓이는 구조더라고요. 램이 모자란다기보다 그 파일이 램을 유난히 많이 달라고 조르던 거였어요. 그래서 저는 바로 쪼개기보다, 무거운 부분을 미리 한 번 중간 렌더로 굳혀서 얹는 식으로 캐시 부담을 덜어봤어요. 쪼개면 관리할 게 늘어서 가볍게 눌러보는 쪽을 먼저 택했던 건데, 컴포넌트 물린 파일은 또 결이 다를 수 있을 것 같아요. 혹시 그 파일만 유독 같은 요소를 반복해서 참조하는 구조는 아닌지, 다들 이럴 땐 어디까지 손보고 넘어가세요?
말씀하신 그 구조가 제 파일하고 거의 겹치더라고요. 열어보니 같은 마스터 컴포넌트를 섹션마다 중첩으로 물려 쓰면서, 그 인스턴스들이 깔릴 때만 압력이 노랗게 넘어가요. 영상의 중간 렌더처럼 저도 무거운 구간은 인스턴스를 떼서 한 번 눌러두는 쪽을 먼저 써봤어요. 쪼개면 관리할 게 늘어서, 그 한 파일의 그 구간만 손보고 넘어가는 편이거든요. 다만 왜 떼뒀는지는 파일 안에 한 줄 남겨둬요. 안 그러면 2주쯤 지나서 왜 플랫하게 뒀는지 저도 또 헷갈리더라고요.
램이 부족한지 파일 구조 문제인지, 그 둘로 가르는 게 맞는 질문일까요. 절반만 맞는 것 같습니다. 저는 커머스라 주문서 파일 하나가 유독 스왑이 올라왔는데, 16GB 자체는 다른 파일에서 멀쩡했거든요. 떼서 보니 결제수단 카드 인스턴스 하나에 오버라이드가 수백 개 걸려 있었습니다. 램이 아니라 그 인스턴스가 매 조작마다 전부 다시 계산되는 게 원인이었어요. 그래서 쪼개기 전에 한 가지만 먼저 보시는 걸 권합니다. 노랗게 뜨는 그 파일에서, 가장 자주 건드리는 컴포넌트가 오버라이드를 몇 개나 물고 있는지. 실사용 빈도로 보면 결국 하루에 수백 번 만지는 인스턴스 한둘이 압력을 다 만들더라고요. 저는 그걸 떼어내 베리언트로 정리하고, 옆에 '이 인스턴스가 무거워서 분리함' 한 줄을 남겨뒀습니다. 안 남기면 다음에 또 같은 자리에서 합치거든요. 파일을 쪼개도 그 무거운 인스턴스가 양쪽에 다 들어가면 똑같습니다. 다들 한 파일에 오버라이드 몇 개까지를 선으로 두세요?
맞는 지적이에요. 제 파일도 떼어놓고 보니 램이 아니라 한 인스턴스였거든요. 같은 마스터를 섹션마다 중첩으로 물리면서 오버라이드가 쌓였고, 조작할 때마다 그게 다 다시 계산되는 게 압력의 정체였어요. 저는 개수로 선을 못 긋겠더라고요. '하루에 몇 번 만지느냐'가 기준이라, 자주 건드리면 베리언트로 떼고 '무거워서 분리함' 한 줄 남깁니다. 안 남기면 2주 뒤 같은 자리에서 또 합치거든요. 경아님은 개수로 선을 두시는 편인가요?
개수로는 안 긋습니다. 저도 주문서 파일에서 레이어 세어서 쪼갰다가 2주 뒤 같은 자리에서 또 합쳤거든요. 개수는 그날 상태라 금방 틀리더라고요. 저는 '하루에 몇 번 만지나'에서 한 칸 더 가서, 베리언트로 뗄 때 '왜 중첩으로 안 돌아갔는지'를 한 줄 붙입니다. 무거워서 뗐다만 남기면 다음에 또 중첩이 편해 보여서 합치거든요. 안 돌아간 판단이 제일 먼저 사라지더라고요.
저도 딱 그 "한 파일만" 패턴을 에펙에서 겪거든요ㅋㅋ 다른 컴포지션은 다 조용한데 유독 한 놈만 열면 프리뷰 걸기도 전에 메모리 압력이 노래지는 경우요. 그때 제가 해본 건 쪼개기 전에 그 파일 안에서 중첩이 제일 깊은 덩어리 하나만 따로 프리컴포(묶어서 별도 파일처럼)로 빼보는 거였어요. 그랬더니 램이 모자란 게 아니라 그 한 덩어리를 매번 통째로 다시 계산하느라 눌렸던 거더라고요. 도현님 쪽 컴포넌트 여러 겹 물린 그 파일도 결이 비슷할 것 같아요. 그래서 저는 파일을 바로 반으로 쪼개기보다, 제일 무거운 중첩 하나부터 떼서 거기만 그런지 먼저 지켜봤어요. 그 한 덩어리가 범인이면 16기가로도 다시 조용해지더라고요. 물론 전 모션이라 컴포넌트 구조 자체는 도현님이 더 잘 보시겠지만요ㅠㅠ
저도 특정 파일 하나만 유독 노랗게 뜬 적이 있는데요. 그때 바로 쪼개지 않고, 메모리 압력이 올라온 순간에 제가 뭘 하고 있었는지를 한 줄로 적어뒀거든요. 파일을 연 직후부터 뜬 건지, 아니면 중첩된 인스턴스를 펼쳐서 수정할 때만 뛴 건지요. 적어두고 보니 저는 열자마자가 아니라 겹친 인스턴스를 편집할 때만 압력이 올라오더라고요. 이 조건을 그 자리에서 안 남겨두면 하루만 지나도 복원이 안 되더라고요. 램이 부족한 건지 구조 문제인지도, 사실 '언제 뜨느냐'를 먼저 재두면 갈리는 쪽이라고 봐요. 파일 여는 것만으로 뜨면 구조에 가깝고, 특정 조작에서만 뜨면 그 조작이 범위라서요. 쪼개실지는 그 조건을 한 번 확인하신 다음에 정하셔도 늦지 않더라고요.