Skills/mY Technutz 2019. 12. 13. 17:44

요즘 다시 혼자서 근무하다보니, 업무량이 훅 늘어나고

분석에 대해서는 반복적인 부분이 많이 발생하는데 그에 대한 시간은 여전히 동일하게 들어서

간편화 하는 방법이 없을까 해서 간단히 python 으로 crash utility 에 대한 extension 을 직접 만들고 있었는데,

하늘아래 새로운 것은 없듯이 역시나 이미 만들어져 있었다는 것을 발견하였다.

그것은 바로 mPyKdump 라는 crash extension 이다.

https://sourceforge.net/p/pykdump/wiki/Home/

일단 커널 코어덤프 분석을 위한 도구인 crash 툴은 C/Python 형태의 외부 스크립트를

내부에서 불러와 사용할 수 있다.

대부분 c 로 컴파일되어 모듈형태로 crash 툴이 실행된 후 로드하는 형태로 사용되는데

mPyKdump 는 파이선 기준으로 작성되어 내용을 수정하더라도 특별히 컴파일이 필요없이

바로바로 적용이 가능하다는 장점이 있었다.

해당 모듈을 이용하여 얼마나 간편하게 기존 삽질을 줄일 수 있는지 확인해보자.

(Host정보 삭제함)


여기까지 PyKdump 모듈의 기능에 대해서 살펴보았다.

이제 커널정보들도 상당히 공개되고 알려져 먹고살기 참 힘든 세상이 되었다.

추가 팁 : 자동으로 mPyKdump 모듈을 로드시키고 싶을 경우,

.crashrc 파일을 만들어 아래와 같이 넣어주면 실행시 자동 로드한다.

.crashrc 는 크래쉬 툴 명령명과 동일하게 만들어 주면 된다.
(.crash64rc 와 같이.)

# cat ~/.crash64rc
extend /usr/local/lib64/mpykdump64.so


'Skills > mY Technutz' 카테고리의 다른 글

The effective crash-utility for vmcore analysis (PyKdump)  (0) 2019.12.13
kernel Dump Analysis #18  (0) 2019.05.11
Kernel Dump Analysis #17  (0) 2019.04.04
libfc: Update rport reference counting bug - 1368175  (0) 2018.03.29
Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2019. 5. 11. 00:21

벌써 18번째 인가... 사실 더 있지만 귀찮아서 안하다 보니.. ㅋㅋ

이번엔 GPU/DRM 관련 버그.. 상당히 따끈따근한 새 버그에 대해서 Digging 해 본다.

커널 4.14.35-1844.4.4 버젼 에 픽스가 포함되어있으므로,

해당 버젼 이상으로 업데이트를 해야 해결할 수 있다.

분석한지 한시간도 안되서 알려진 버그를 찾았다는게 개인적으로 나름 웃긴 부분이며,

물론 실제로 고객이 분석을 요청했을때, 이렇게 상세하게 지원 해주지는 않는다.

업무 특성상 사실, 솔루션만 제공하면 되니까 그러는 것도 있지만,

돈내고 받는 서비스라는 생각에 이해할 수 있는 기반도 없이 스터디를 요구하는 경우가 많아서이기도 하고..

(이전에 사과먹다만 회사 내부 커널개발자라는 놈이
아주 미친/미친듯이 질문을 한적이 있는데 답답해 미치는줄 알았었...)

블로그에 상세내용을 올리는 것은 분석에 대한 기법을 공유하기 위해서다.

끝.

'Skills > mY Technutz' 카테고리의 다른 글

The effective crash-utility for vmcore analysis (PyKdump)  (0) 2019.12.13
kernel Dump Analysis #18  (0) 2019.05.11
Kernel Dump Analysis #17  (0) 2019.04.04
libfc: Update rport reference counting bug - 1368175  (0) 2018.03.29
Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2019. 4. 4. 23:19

재밌는 리턴코드가 발견되어서 간만에 좀 디깅을 해봤다.

      KERNEL: /share/linuxrpm/vmlinux_repo/64/3.10.0-693.el7.x86_64/vmlinux
    DUMPFILE: 127.0.0.1-2019-01-17-00_38_36.zip_extract/vmcore  [PARTIAL DUMP]
        CPUS: 40
        DATE: Thu Jan 17 00:38:38 2019
      UPTIME: 39 days, 18:26:52
LOAD AVERAGE: 0.19, 0.20, 0.24
       TASKS: 1420
    NODENAME: **********
     RELEASE: 3.10.0-693.el7.x86_64
     VERSION: #1 SMP Wed Aug 2 06:49:08 PDT 2017
     MACHINE: x86_64  (2199 Mhz)
      MEMORY: 63.9 GB
       PANIC: "BUG: unable to handle kernel paging request at ffffffffc0500790"
         PID: 72639
     COMMAND: "kworker/15:0"
        TASK: ffff880dc2744f10  [THREAD_INFO: ffff881052fb8000]
         CPU: 15
       STATE: TASK_RUNNING (PANIC)

crash64> log

[   37.351715] ip6_tables: (C) 2000-2006 Netfilter Core Team
[236233.529248] perf: interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 79000
[346636.325549] perf: interrupt took too long (3127 > 3126), lowering kernel.perf_event_max_sample_rate to 63000
[602033.211929] perf: interrupt took too long (3916 > 3908), lowering kernel.perf_event_max_sample_rate to 51000
[2952215.839114] perf: interrupt took too long (4941 > 4895), lowering kernel.perf_event_max_sample_rate to 40000
[3436125.331154] BUG: unable to handle kernel paging request at ffffffffc0500790
[3436125.331196] IP: [<ffffffffc0500790>] 0xffffffffc050078f
[3436125.331224] PGD 19f5067 PUD 19f7067 PMD 8598de067 PTE 0
[3436125.331251] Oops: 0010 [#1] SMP
[3436125.331270] Modules linked in: ip6table_filter ip6_tables sctp_diag sctp dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag binfmt_misc iptable_filter bonding sb_edac edac_core intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass ipmi_ssif crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt dcdbas iTCO_vendor_support mxm_wmi sg ipmi_si ipmi_devintf ipmi_msghandler pcspkr mei_me mei lpc_ich shpchp wmi acpi_power_meter ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ixgbe ahci crct10dif_pclmul crct10dif_common igb crc32c_intel libahci megaraid_sas libata mdio i2c_algo_bit ptp i2c_core pps_core dca dm_mirror dm_region_hash
[3436125.331620]  dm_log dm_mod
[3436125.331629] CPU: 15 PID: 72639 Comm: kworker/15:0 Not tainted 3.10.0-693.el7.x86_64 #1
[3436125.331661] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.5.5 08/16/2017
[3436125.331721] Workqueue: xfs-cil/dm-3 xlog_cil_push_work [xfs]
[3436125.331746] task: ffff880dc2744f10 ti: ffff881052fb8000 task.ti: ffff881052fb8000
[3436125.331776] RIP: 0010:[<ffffffffc0500790>]  [<ffffffffc0500790>] 0xffffffffc050078f
[3436125.331810] RSP: 0018:ffff881052fbbca0  EFLAGS: 00010286
[3436125.331832] RAX: ffffc90007396450 RBX: ffff88100ce8dc08 RCX: 0000000000000000
[3436125.331860] RDX: 0000000000000480 RSI: ffff880c9fbd7980 RDI: ffffc900073968d0
[3436125.331887] RBP: ffff881052fbbd38 R08: 0000000000000000 R09: ffffc90007396450
[3436125.331915] R10: 0000000000000480 R11: 0000000000018d8c R12: 0000000000000480
[3436125.331943] R13: 0000000000000033 R14: 0000000000000002 R15: ffff880c9fbd7000
[3436125.331971] FS:  0000000000000000(0000) GS:ffff88105dfc0000(0000) knlGS:0000000000000000
[3436125.332002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[3436125.332026] CR2: ffffffffc0500790 CR3: 000000067136f000 CR4: 00000000003407e0
[3436125.332053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[3436125.332081] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[3436125.332113] Stack:
[3436125.332124]  ffff880a3aa68010 0000000000000000 ffff88085522f400 000000000c041837
[3436125.332158]  0000000000018d8c 0000000000000480 ffff88085522f528 0000000000000000
[3436125.332192]  0000000000000480 ffff881000006244 ffff880c9fbd7038 0000625000000001
[3436125.332224] Call Trace:
[3436125.332254]  [<ffffffffc04021d8>] xlog_cil_push+0x2a8/0x430 [xfs]
[3436125.332293]  [<ffffffffc0402375>] xlog_cil_push_work+0x15/0x20 [xfs]
[3436125.332322]  [<ffffffff810a881a>] process_one_work+0x17a/0x440
[3436125.332347]  [<ffffffff810a9638>] worker_thread+0x278/0x3c0
[3436125.332371]  [<ffffffff810a93c0>] ? manage_workers.isra.24+0x2a0/0x2a0
[3436125.332398]  [<ffffffff810b098f>] kthread+0xcf/0xe0
[3436125.332420]  [<ffffffff8108ddeb>] ? do_exit+0x6bb/0xa40
[3436125.332443]  [<ffffffff810b08c0>] ? insert_kthread_work+0x40/0x40
[3436125.332470]  [<ffffffff816b4f18>] ret_from_fork+0x58/0x90
[3436125.332493]  [<ffffffff810b08c0>] ? insert_kthread_work+0x40/0x40
[3436125.332518] Code:  Bad RIP value.
[3436125.332538] RIP  [<ffffffffc0500790>] 0xffffffffc050078f
[3436125.332564]  RSP <ffff881052fbbca0>
[3436125.332580] CR2: ffffffffc0500790

아쉽지만, 여기까지만 하고 다음에는 uek 와 관련된 내용으로 포스팅을 해야할것 같다.

내용을 볼수 없어서 비교가 불가하기때문이다 흑... 갑자기 용두사미가 된거같은데 뭐 내맴.



'Skills > mY Technutz' 카테고리의 다른 글

The effective crash-utility for vmcore analysis (PyKdump)  (0) 2019.12.13
kernel Dump Analysis #18  (0) 2019.05.11
Kernel Dump Analysis #17  (0) 2019.04.04
libfc: Update rport reference counting bug - 1368175  (0) 2018.03.29
Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018. 3. 29. 13:31

결국 같은 이슈였다.

내가 전에 올렸던 Kernel Dump Analysis #14 / #15 두개의 이슈..

결국 #15 와 #14 모두 동일한 rport reference count 관련 race condition bug 였다.

비록 양상이 다르긴 했지만 모두 Kref 를 감소시키며 0 으로 만드는 과정에서

Race condition 으로 인해 다른 메모리 값을 참조하게 되는 버그였다.

아래는 해당 버그에 대한 Patchwork (GIT) 링크 이다.

https://patchwork.kernel.org/patch/9132823/

대략 reference count초기화 하는 과정에서 Mutex lock 을 걸어

Violation 을 방지하려고 했는데, 매 타임마다 Locking 을 하고 그 값을 대기하다보니

대기시간중에 다른 스레드가 해당 구조체에 엑세스 할 기회를 만들어주게 되어

결국 해당 값이 바뀌어 버리는 일이 생길 수 있다는 것이고, ( Race condition )

이 과정을 단순히 Remote port 에 대한 참조카운트를 추가하여

해당 값을 Lookup 할때 (디스크 제거시에만) 참조값을 줄이면 되기 때문에

디스크를 제거/검색 하는 과정에서 매번 디스크 뮤텍스를 걸 필요가 없게 수정한 이다.

개 빡치는것은, 내가 분명 두가지 모두 최종 Call trace 는 다르지만 모두 libfc 모듈에서

fc_lport / fc_rport 관련 구조체에 대한 Referencing 에서 나오는 이슈이므로

동일한 것같다고 이야기 했지만,

커널 개발팀에서 계속 "아니다, 다르다, 재현해서 다시 살펴봐야 한다" 라고 우기는 바람에

고객이 너무 빡쳐서 "그냥 다 때려쳐 씨밤, 너네 구려!" 이랬다는 것...

졸라 중요고객이라고 지랄들을 해대서,

어떻게 해야 할지 몰라 냅뒀더니 두달이 지난 지금에서야

We are unable to reproduce the crash in QA setup which is often hard to do because it is not possible to replicate customer environment in the lab.
However, The two core dumps even though showed different symptoms, but the underlying root cause is the same, the kref count being zero. 

Rajan provided the Ksplice patch and rpms which has the fix to address kref handling.

'응 그래, 재현이 졸라 안되서 미안하지만...그래도 동일 이슈맞는것 같아

우린 이미 앞선 패치를 통해 솔루션을 제공했어. 우린 잘했다고'

이지랄을 떨고 있다.

개발자들 일안하냐? 내가 호구로 보이냐? ㅎㅎㅎㅎㅎ 아몰랑!


'Skills > mY Technutz' 카테고리의 다른 글

kernel Dump Analysis #18  (0) 2019.05.11
Kernel Dump Analysis #17  (0) 2019.04.04
libfc: Update rport reference counting bug - 1368175  (0) 2018.03.29
Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018. 2. 22. 13:27

와.. 대박... 일이 엄청나게 들어와..

공격적으로 오라클 리눅스를 장사하면 내가 쓰일만한 일이 있긴 하구나 하면서도

일이 이렇게 많아지면 개빡쳐서 아무것도 하기 싫어지는 현자타임같은게 온다는..

무튼, 요즘 핫하게 밀려들어오는 업무량 덕에 코어분석 일도 숭풍숭풍 막 쳐 들어오는..

이번에는 레드햇 커널 즉, Oracle Linux 에서 Cmompatibility 를 위해 제공하는

Redhat Compatible Kernel ( RHCK ) 와 관련된 커널 덤프 분석을 해주시겠다.

Technical Preview 이기 때문에 해당 부분에 대한 코드는

ASSERTCMP(op->state, ==, FSCACHE_OP_ST_DEAD);

로 수정되는 식으로 상황을 정리하는 코드가 추가된 것 같다.
( 수정된 코드 다운받거나 찾기 귀찮다! 바쁘다. 점심안에 써야한다 글을. )

물론 픽스는 해당 fscache 모듈을 사용하지 않도록 하거나,

( cachefilesd 데몬을 Disable 한다. )

ELSA-2017-0307 또는 ELSA-2017-0817 ( RHSA-2017-0817 대응) 에서 권고하는

kernel-2.6.32-696.el6 이후의 최신 버젼으로 업그레이드 하거나

6.8 GA kernel-2.6.32-642.el6 이하 커널로 다운그레이드 하면 된다고

Redhat 에서 이야기 하는 것 같다.

사실 개인생각으로는 커널 업그레이드를 해봤자 동일할것 같긴 해서

구지 필요하지 않다면 Cachefilesd 를 Off 하는게 더 좋을것 같다고 생각된다.

mount option 에서 fsc 가 생겼는데 이게 없으면 자동으로 fscache 가 활성화 된다고 하는 것 같다.

레드햇 이슈라 명확하게 솔루션 코드가 확인되지 않는 상태라 잘 모르겠으나

분석 방법이랑 워크어라운드 기입되 있음 이미 난 충분히 세계를 위해 기여한거시다...

'Skills > mY Technutz' 카테고리의 다른 글

Kernel Dump Analysis #17  (0) 2019.04.04
libfc: Update rport reference counting bug - 1368175  (0) 2018.03.29
Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
Kernel Crash dump Analysis - #13  (0) 2017.12.20
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018. 2. 19. 13:18

저번 14 에 이어진 내용이라고 볼 수 있다.

지난시간 왜 시스템 커널 분석에서 fc_stat, fc_lport 에 집중했는지 나오는 부분이다.

이전 게시글에서와 동일하게 ffff880103e67a00  를 참조하는 부분에서 문제가 발생하였다.

따라서 fc_lport 에 관련되어 메모리를 사용함에 있어, 이미 해제된 메모리를 재참조하거나,

메모리 corruption 조건이 발생되고 있다는 것을 의미한다.

역시 저번 게시글과 같이 해당 코드에 논리적 오류나 Race condition 발생 여부,

Used-after-freed 현상에 대해서 더 살펴봐야 하는 상태이지만,

코드 상 특별히 문제될만한 부분은 발견되지 않았다는 점이 현 문제의 가장 큰 난관이다.

지금은 개발팀에서 in-house 로 동일 환경을 구성 후 재현테스트를 하고 있는 중이다.

이는 장비에 대한 특성 ( 펌웨어 문제 또는 하드웨어 관련 된 정보의 괴리 ),

즉 하드웨어 문제를 배제할 수 없는 의심스러운 부분이 있다는 것을 의미한다.



posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018. 2. 13. 23:40

이젠 뭐, 커널에 대한 덤프 분석이라기 보다는

CRASH tool 의 사용법과, 이슈에 따라서 분석을 진행하는 방법에 대한 Guide 가 되어가는 것 같다.

이전엔 주절주절 말을 많이한것 같았는데, 오늘은 주로 코드나 어셈의 흐름을 위주로 설명해 볼까 한다.

시스템이 갑작스럽게 코어와 함께 리붓되었단다.

참고로 현재 이슈는 다른 이슈와 연결되어 발생한 이슈로써,

아직 해결되지는 않은 이슈이며, fc_lport 의 값을 찾기 위한 이유에 대해서 밝히지 않고 있었다.

물론 이어지는 덤프분석이 또 있을 것이며, 거기서 이유가 밝혀질 것이다.

여기서 중요한 부분은 위의 로그에서 빨간색으로 표현한 두줄의 스택로그이다.

현재 의심되는 부분은 RBX 로 들어가는 메모리가 Corruption 되거나 used-after-freed 현상인데,

두줄의 로그를 보았을 경우 used-after-freed 가 되지 않을까 싶다.

이번 경우에는 확실히 used-after-freed 현상이 가장 가깝기 때문이다.

즉, 해제된 것을 다시 사용하거나, Double free race condition 등이 발생하고 있다는 것이다.

물론... 소스코드상에서는 아직 오류를 찾을 수 없는 상황이다.

보다 자세하고 큰 그림은 다음 분석을 통해 함께 그려보도록 하겠다.

'Skills > mY Technutz' 카테고리의 다른 글

Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
Kernel Crash dump Analysis - #13  (0) 2017.12.20
커널이 지원하는 기능을 확인하는 습관.  (1) 2017.02.06
Kexec/Kdump 의 제약사항에 대해서  (4) 2016.01.14
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2017. 12. 20. 11:29

귀차니즘에 안하고 있던 커널 덤프 분석 13번째 케이스 공유.

- Symptom : 특정 시간대를 기점으로 HA 로 구성된 서로 다른 세개의 시스템 세트(총 6대)가 비슷한 형태의 메시지를 보이며 리부팅.

일부 HA 및 RAC 시스템의 경우 5분간격으로 리부팅 되는 등, 심각한 서비스의 영향도를 초래하는 상황.

실재로 고객은 해당 서버에서 LTO 테잎 라이브러리를 이용해 백업을 받는 작업이 있었고,
이때마다 리부팅이 발생한 것으로 판단된다.

처음에는 Tape Driver 의 문제를 의심했으나,

Null point 에러와 여러대의 다른 Cluster set 에서 동일하게 발생하고 있었기 때문에

버그를 찾아보게 되었고, 픽스를 확인할 수 있었다.

물론 이 버그에 대한 패치는 완벽하게 릴리즈 되지 않았고, QA 중이며, UEK4QU6 에 출시되는 4.1.12-119 버젼에 포함될 것이다.

** 완전 새로운 버그였으면 그냥 새 버그로 오픈하거나 커널메일링에 문의를 할 수 있던 상황인데 아쉽..(?)


posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2017. 2. 6. 19:01

가끔 커널소스를 받아 make config 또는 make menuconfig 를 해보면,

자신의 커널이 어떤 기능을 디폴트로 지원하고 있는지 확인 할 수 있다.

이렇게 보다 보면 커널 디버깅에 대한 기능들도 일부 얻을 수 있고,

어떤 기능들을 리눅스에서 지원하고 있는지  확인 할 수 있어 가끔 도움이 되곤 한다.

참고로 난 Memory debugging 을 좀 해볼게 있어 디버깅모드를 상당히 많이

Enable 시켜 Recompile 중이다. 특히 debugfs 와 sysfs, ftrace 의 기능들을 좀 더 추가했다.

( 사실 Perf 랑 DTrace 등을 이용해도 되는데 왜때문에? ㅠㅠ )

또한 사용된 리눅스 커널은 바닐라 커널이 아닌 오라클의 UEK2 커널이며,

호환성 등을 위해 Linux kernel 2.6.39 (Flesh-Eating Bats with Fangs) 와

3.0.60 sneaky weasel 을 믹스하여 개발된 커널로

컴파일되는 버젼은 2.6.39 로 컴파일된다.

이건 오라클 UEK2 의 최신 바닐라커널인 셈이다.


주 : 자주는 보지 말자 -_-

주2 : 원래 LWN 기사 관련 번역을 어제 작성하다가 다 날려먹어서 멘붕에 그냥 간단한걸로..

posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply 푸우

    좋은 정보 감사해요

    2017.02.06 20:40

Skills/mY Technutz 2016. 1. 14. 23:08

정말 백만년만의 글인가.... 하고 보니 작년 6월에 글 썼었네... ㅎ


일년에 두개정도면 많은거 같은데..


무튼 어느순간 일이 증가하고, 같이 일하는 사람들이 생겼다 없어졌다 다시 생기는 등


신경써야 할 것들이 많았던 터라 영 공부를 할 수 없었는데,


최근 회사 엔지니어들이 주고받는 메일링 리스트를 보고 다시 이쪽저쪽 들쑤시려고 하는 중...


메일링 리스트에 고객이 많은 메모리를 쓰고 있고, 어떤 이슈가 생겨서, kdump 설정을 통해 덤프를 떠


분석하려고 하는데 이게 자꾸 설정이 안된다는 것이다..


답변으로 오는 것들은 대부분 이것저것 crashkernel 값을 조절해 보라 정도...


그래서 살펴보았다 어떤 공식을 통해 해당 영역이 Allocation 되는지를 말이다.




여기서 내 결론은 일반적으로 crash kernel 은 전체 메모리를 완벽하게 다 뜬다고 볼 수 없으며,


Kernel 에 대한 영역을 위주로 커널이 갖고 있는 PTE 등의 Linked List 정보를 덤프한다고 볼 수 있으므로,.


물리적 메모리 양이 많이 있다고 해서 crashkernel 을 무턱대고 올리는 것이 아니라,


2G - 256M 를 기준으로  64M 씩 올려가면서 테스트 해야 한다는 것이다...


참고로 레드햇 기준으로는 2G-256M, 6G - 512M, 8G - 768M, 그 이상이어도 869M 넘지 않도록


권고하고 있다... ( 난 8G - 768 M 도 too much 하다고 본다.. )


이슈에 대한 추이가 기대되는 부분이다...














posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply BlogIcon k

    최대...768m...그정도면..1tb 메모리도이상없는듯...
    메모리보다는....장착되어있는..디바이스에 따라 차이를 보이는듯하네요...물론..메모리도 상관 있는듯...

    2016.01.15 18:56
    •  Addr  Edit/Del Favicon of https://seblog.mirr4u.com BlogIcon mirr

      드라이버 등에 영향을 받을 수 는 있죠, 문제는 100테라 넘는 애들에 대한 문제인데, 이부분에선 사실 글에서 언급하지 않은 copy_to_user 의 개선이필요하다고 보는거죠 이부분에서 memcpy 부분의 효율 개선이나 다른 방식의 improve 가 필요하다고 봐요.. OOM 이 발생했다는게 이슈니까요 ㅎㅎ

      2016.01.16 00:14 신고
  2.  Addr  Edit/Del  Reply BlogIcon k

    최대...768m...그정도면..1tb 메모리도이상없는듯...
    메모리보다는....장착되어있는..디바이스에 따라 차이를 보이는듯하네요...물론..메모리도 상관 있는듯...

    2016.01.15 18:56
  3.  Addr  Edit/Del  Reply Favicon of http://seblog.mirr4u.com BlogIcon 미르

    낚임.. 결국 800M 로 덤프 성공.. OOM 부분은 역시 각종 모듈이 영향을 준 것이긴 한데, kdump 에선 이를 위해 blacklist 라는 옵션을 kdump.conf 레벨에서 제공..
    이를 다 블랙리스트로 처리하고 dump 를 뜨면 충분히 떠진다는 점....

    2016.01.18 15:20