- 스마트폰 로그버퍼당 크기와 인터넷 로딩속도
-
작성일:08-24 20:38
정보력:11500 친절도:2933
조회수:10433
첨부1 : Screenshot_20210824_233448_Settings.jpg(129.2 KB), Download : 7
첨부2 : Screenshot_20210825_001121_Samsung_Internet.jpg(186.1 KB), Download : 4
어느정도가 좋은가요?
전문가들? 도 의견이 다르네요.
4M로 되어 있던것 개발자옵션켜서
16M로 바꾸어 써보고 있습니다.
전체적 성능? 프로세서 면에서는 떨어진다
하더라도?
인터넷 속도 로딩등은 좀 빨리진것 같아요.
체감일까요?
-
-
초록물고기
08-24 20:50
정보력:2400 친절도:13497
혹시 저 로그버퍼가 android debug log를 의미하는건가요? debug목적의 로그라면 일반인은 필요가 없는 영역이라 오히려 이 버퍼를 줄이거나 꺼야 시스템에 부하도 줄고 메모리도 더 많이 쓸수 있을텐데요...????
추천:vendetta
추천:현구아빠
추천:터쥐 -
vendetta
08-24 20:52
정보력:6860 친절도:36650
[캐시] 버퍼가 아니라 [로그] 버퍼라 사용자 입장에서는 굳이 신경 안써도 될 겁니다.
윈도 오류 로그 크기 늘린다고 인터넷 빨라지는거 아니고
윈도 이벤트 뷰어도 평생 써본일이 없는 사람들이 대부분인 것처럼요.
고치는 사람 입장에서나 뭐가 문제인지 기록으로 필요한게 말그대로 로그죠.
https://r1.community.samsung.com/t5/%EA%B0%A4%EB%9F%AD%EC%8B%9C-s/%EB%A1%9C%EA%B1%B0-%EB%B2%84%ED%8D%BC-%ED%81%AC%EA%B8%B0%EB%A5%BC-%ED%82%A4%EC%9A%B0%EB%A9%B4-%EC%A0%95%EB%A7%90-%EC%86%8D%EB%8F%84%EA%B0%80-%EB%B9%A8%EB%9D%BC%EC%A7%80%EB%82%98%EC%9A%94/td-p/3036434
https://r1.community.samsung.com/t5/%EA%B0%A4%EB%9F%AD%EC%8B%9C-s/%EC%96%B4%EC%A0%9C-%EC%98%AC%EB%9D%BC%EC%98%A8-%EB%A1%9C%EA%B1%B0%EB%B2%84%ED%8D%BC%ED%81%AC%EA%B8%B0-%EA%B4%80%EB%A0%A8/td-p/4173809
시스템성능담당
Moderator
옵션
04-17-2020 05:57 PM ·
갤럭시 S
고객님 안녕하세요?
시스템 성능담당입니다.
로그 버퍼는 단말의 오류 분석을 위한 메모리 공간의 크기를 말하며,
사이즈가 커지면 단말이 다른 용도로 사용 가능한 메모리 공간이 줄어들게 되어
성능면에서는 오히려 불리하게 됩니다.
멤버스 등을 통해 지원을 받기 위해 충분한 양으로 확보하는 목적이 아니라면 로그 버퍼 크기는 작게 유지하시는 것이 성능 면에서는 좋습니다. -
vendetta
08-24 21:00
정보력:6860 친절도:36650
디버깅을 해야하는 개발자 입장에서야 사용자가 크게 잡고 써주면야 혹시라도 오류 생길 때 참조할 데이터가 많아서 좋겠지만, 사용자는 봐도 이해를 못하는 기록을 굳이 많이 할당하고 있을 필요가 없지요. 개발자나 제조사가 출고시 다시 그 적정량 정도로 줄여서 출고하는건 다 그런 이유도 있을 것이고요. 반대로 로그 버퍼를 디폴트로 많이 잡아서 출고했다면 인터넷으로 가루가 되게 엄청 까였을 겁니다. -
vendetta
08-24 21:04
정보력:6860 친절도:36650
아래 같이 그냥 퍼나르는 글이 많은데 브라우저나 앱의 캐시 버퍼와 시스템 오류 로그 버퍼 차이를 전혀 모르고 그냥 이것저것 시험삼아 플라세보 효과마냥 해보라는 것이지요. 현재의 전송속도로는 브라우저의 캐시 버퍼도 최소한으로 줄이는게 좋은 상황입니다. ADSL 때에나 속도가 느리니 미리 방문한 곳들 이미지 파일 등을 로컬에 캐시로 잡아두는 것이었고요.
https://terran6820.tistory.com/92
추천:NullStr -
체리쉬
08-24 21:09
정보력:11500 친절도:2933
스마트폰에 동일하게 적용이 될까요? 생활의 달인에서 동영상 재생 비교영상이 있더라구요. 높은 버퍼가 빨랐습니다. -
체리쉬
08-24 21:23
정보력:11500 친절도:2933
저는 전문가는 아닙니다만. 우선 로딩속도는 같은 네트워크임에도 불구하고 체감이 아니라 실제로 빠르네요. 투피홈피기준 테스트한번 해보세요. 다만 배터리 소모는 약간 걱정입니다. -
vendetta
08-24 21:49
정보력:6860 친절도:36650
전송속도에 영향을 준다기보다는 백그라운드에도 떠 있는 무수한 앱들의 여러 로그 처리의 부하를 [지연] 시켜줘서 [일시적]으로 빠르게 느낄 수는 있을 것 같습니다. 256K 단위로 로그 정리 후 처리할 것(이게 안드로이드의 경우 의외로 부하량이 크다면)을 4배, 16배, 64배 이렇게 지연시킬 수 있을테니까요. 그런데 최종적으로 64배 만큼의 로그가 누적되고 다시 갱신되는 시점부터는 비슷해 질 것이고요.
Log 자체는 말그대로 뭔가 설정이거나 옵션도 아니고 그냥 [기록]일 뿐이고 개발자 공식답변으로도 굳이 크게 만들 필요가 없습니다. 안드로이드 OS 자체의 Log 처리과정의 최적화나 부하량 문제로 수많은 앱들의 [기록] 과정 자체가 딜레이의 요소일 수는 있겠고 이게 일시적으로 최초의 경우에만 기존값보다 16배나 64배 정도 쌓아뒀다가 나중에 처리하게 할 뿐이겠지요. 결국 꽉차면 처리하는 속도는 기존과 동일해질 것이고요.
https://developer.android.com/studio/command-line/logcat
추천:바꿔바
추천:NullStr -
체리쉬
08-24 21:52
정보력:11500 친절도:2933
일시적 일수 있겠군요. 당장 체감이 있기는 합니다. 로그버퍼이해가 상세히 안되네요. -
vendetta
08-24 22:11
윈도 등은 개발된지 수십년이라서 log 처리과정에서 뭔가 지연이 있는 상황은 사람들이 아예 염두에 두지 않는데(대부분 HDD 같은 스토리지의 지연) 안드로이드는 구조상 기록 과정에 딜레이가 있다면 가능한 현상 같습니다.
제 폰에 앱 갯수가 기본 시스템 앱 포함 249개 인데, 윈도에서 제가 설치해서 쓰는 프로그램 갯수는 20개 정도 될것이고 그나마 이것도 동시에 띄워서 쓰거나 백그라운드에 떠 있는 것도 아닙니다. 그런데 안드로이드의 경우 사용자의 앱 사용 패턴에 따라(특히 상시 SNS 등) 로그 처리 부하량이 앱이 많아지면 많아질수록 기하급수적으로 윈도 등과는 확연히 다를 수도 있을 것 같습니다. -
vendetta
08-24 22:15
정보력:6860 친절도:36650
저게 일시적인게 아니라 중장기적으로 실효가 있는 옵션이면 일부러라도 제조사들이 경쟁적으로 최대 설정값으로 출고 당시부터 내놓을 겁니다.
벤치마크툴에만 풀로드로 반응하도록 조작하기도 하는 곳인데 말이죠. -
vendetta
08-24 22:20
정보력:6860 친절도:36650
1. 256K 만큼 쓰레기 하적장에 던져둔다 - 꽉차면 내가 버릴 쓰레기 만큼 기존에 쌓인 쓰레기를 꺼내서 쓰레기 차에 실어야 한다. 그 후에 가져온 쓰레기를 하적장에 던진다.
2. 쓰레기 하적장이 64배로 늘어났다 - 기존에 쌓인거 빼낼 필요없이 그냥 계속 던져 두고 오기만 하면 된다. 오, 시간단축!
어느정도 기간은...
- 확장한 64배의 공간도 꽉차면 1의 과정과 동일해진다.
이 정도로 예상 됩니다. -
vendetta
08-24 22:29
정보력:6860 친절도:36650
256KB가 작아보일 수 있긴한데 영문기준으로 하자면 200자 원고지 1280매 분량입니다. 서적으로 만들어도 단행본 한권은 되는 분량이지요. 이게 64배로 늘어나면 백과사전 전질급이나 책장 하나 정도를 넘어가겠고요. 그만큼의 일시적 여유텀을 만들어주는 1회성 심리적 안정감 정도.
언젠가는 현재 시점과 동일한 수준으로 다시 상대적으로 느려지는 것이니 불필요하게 수시로 백그라운드에 상주하는 앱들을 줄이거나 공초를 하거나 새폰을 구매하거나 등등 근본적인 원인을 해결해야겠지요. -
vendetta
08-24 23:26
정보력:6860 친절도:36650
제 경우는 가능한 가볍게 쓰려는 편이라 설정 값을 다 바꿔도 차이는 없네요.
빨라지셨다가 어느시점에 다시 원래대로 느리게 돌아온다면 로그 없음을 해보거나 256k로 줄였다가 다시 16M로 늘려보시면서 그때 그때 테스트해보시는 방법도 있겠네요. -
체리쉬
08-24 23:31
정보력:11500 친절도:2933
감사합니다. 공부했어요..좋은폰써야겠네요.~^^ -
장풍高手
08-24 23:32
정보력:3250 친절도:8319
이게... 벤데타님은 그냥 본인의 검색력이 좋다고 항상 말씀을 하시긴 하는데...
뭘 알아야 검색을 해도 알아보고 같이 이야기도 할수 있는거 아닌가요..?
진짜 엄청난 분이시군요..............=_=......
전 써놓으신거 봐도 무슨 이야기인지............ -
제이제이
08-25 07:54
정보력:28930 친절도:27412
흠흠흠...
-
Jhelom
08-26 03:53
정보력:3060 친절도:5794
자바는 메모리 할당/해제가 자동으로 이루어지다 보니 로그 버퍼가 작은 경우 garbage collection이 자주 일어나서 전체적인 시스템 성능이 저하되는게 아닐까요?
10년전 안드로이드 폰들은 garbage collection이 거지 같아서 머만 하면 뻗고 그랬는데, 지금은 좀 나을것 같긴 하지만요... -
vendetta
08-27 13:18
정보력:6860 친절도:36650
검색해보니 안드로이드 스마트폰의 Log 처리 방식과 관련해서 저장장치의 특성도 같이 걸려 있을 듯 하네요.
앱이 많고 처리할 로그도 많고 전송도 HDD나 SSD 같은 양방향 동시가 아니고 한 상황의 복합적인.
이걸 아예 그냥 계속 엄청나게 미뤄두다가 처리하게되니 일시적으로 빨라질 수도 있을 것 같습니다.
eMMC 4.5 보급기종 기준으로 최대 읽기 140MB/s, 쓰기 50MB/s
https://en.wikipedia.org/wiki/MultiMediaCard#eMMC
스마트폰 저장공간, 용량은 같아도 성능은 다르다? eMMC와 UFS!
https://news.skhynix.co.kr/1463
우선 eMMC는 병렬 인터페이스(Parallel x8), UFS는 직렬 인터페이스(Serial)로 인터페이스 방식이 다릅니다.
이런 인터페이스의 방식에 따라서 eMMC 병렬 인터페이스는 한 번에 한 방향으로만 데이터를 전송할 수 있습니다.
즉, 동시에 데이터를 읽고 쓰는 것이 불가능한 방식이죠. -
체리쉬
08-28 09:55
정보력:11500 친절도:2933
일반인들은 구분이 쉽지않겠습니다.**
댓글 쓰기를 위해서 로그인해주세요 로그인