darren, dev blog

kernel study 03: Understanding the Calculation of Load Average in Linux Kernel

DarrenKwonDev — Fri, 29 Dec 2023 04:50:38 +0900

아래 블로그에서 좀 더 깔끔하고 제대로 읽을 수 있습니다.

https://darrenkwondev.github.io/posts/2023-12-28_kernel_study_03.md/

kernel study 03: Understanding the Calculation of Load Average in Linux Kernel | darrenkwon.dev blog

/proc/loadavg The first three fields in this file are load average figures giving the number of jobs in the run queue (state R) or waiting for disk I/O (state D) averaged over 1, 5, and 15 minutes. They are the same as the load average numbers given by upt

darrenkwondev.github.io

Linux kernel v6.7-rc7 기준으로 작성되었습니다.

Load average

definition

/proc/loadavg
The first three fields in this file are load average figures giving the number of jobs in the run queue (state R) or waiting for disk I/O (state D) averaged over 1, 5, and 15 minutes. They are the same as the load average numbers given by uptime(1) and other programs. The fourth field consists of two numbers separated by a slash (/). The first of these is the number of currently runnable kernel scheduling entities (processes, threads). The value after the slash is the number of kernel scheduling entities that currently exist on the system. The fifth field is the PID of the process that was most recently created on the system.

즉, load average는 1분, 5분, 15분 동안 process status가 R(run queue에 적재) 또는 D(waiting for disk I/O)인 job(task)의 수이다.[^1] 그러나 단순히 task의 수 만으로는 시스템 부하를 판단하기는 어렵다. 현재 가동 중인 cpu 코어의 갯수와 고려하여 다른 측면까지도 고려해야 한다. 본 포스트에서는 시스템 부하를 판단하는 방법에 대해서는 다루지 않고, load average가 어떻게 계산되는지에 대해서만 알아보자.

[^1]: process status에 대해서는 이전 포스트를 참고하자.

load average는 다음과 같이 다양한 방법으로 조회할 수 있다.

cat /proc/loadavg
uptime
top -b | head -1

tracking how load average is calculated

strace

strace uptime

출력된 덤프 하단을 보면 다음과 같은 점들을 확인할 수 있습니다.

# uptime 실행
execve("/usr/bin/uptime", ["uptime"], 0xfffff2486300 /* 24 vars */) = 0

# 메모리 할당 및 매핑
brk(NULL)                               = 0xaaaaf84c2000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffaf954000

... 생략

# /proc/loadavg를 RDONLY로 open하여 fd 4에 할당
openat(AT_FDCWD, "/proc/loadavg", O_RDONLY) = 4

# fd 4의 시작으로 SEEK_SET. 처음부터 파일을 읽을 것을 위함.
lseek(4, 0, SEEK_SET)                   = 0
read(4, "0.00 0.00 0.00 3/190 26203\n", 8191) = 27

... 생략
+++ exited with 0 +++

결국 uptime은 /proc/loadavg를 읽어오는 것에 불과합니다.

top에 출력되는 load average도 마찬가지입니다.
strace -e openat top -b -n 1를 실행하여 덤프 하단을 살펴보면 /proc/loadavg를 읽어오는 것을 확인할 수 있습니다.

그렇다면 구체적으로 /proc/loadavg이 어떻게 계산되는지 kernel을 살펴보겠습니다.

loadavg_proc_show

/fs/proc/loadavg.c 파일의 코드에는 다음과 같은 내용이 존재합니다. 짧은 코드니 header를 제외한 전부를 첨부해보겠습니다.

// /fs/proc/loadavg.c

static int loadavg_proc_show(struct seq_file *m, void *v)
{
    unsigned long avnrun[3];

    get_avenrun(avnrun, FIXED_1/200, 0);

    seq_printf(m, "%lu.%02lu %lu.%02lu %lu.%02lu %u/%d %d\n",
        LOAD_INT(avnrun[0]), LOAD_FRAC(avnrun[0]),
        LOAD_INT(avnrun[1]), LOAD_FRAC(avnrun[1]),
        LOAD_INT(avnrun[2]), LOAD_FRAC(avnrun[2]),
        nr_running(), nr_threads,
        idr_get_cursor(&task_active_pid_ns(current)->idr) - 1);
    return 0;
}

static int __init proc_loadavg_init(void)
{
    struct proc_dir_entry *pde;

    pde = proc_create_single("loadavg", 0, NULL, loadavg_proc_show);
    pde_make_permanent(pde);
    return 0;
}
fs_initcall(proc_loadavg_init);

cat /proc/loadavg의 결과를 고려해보면 0.01 0.01 0.00 1/188 26290 와 같은 꼴로 출력되었는데 loadavg_proc_show 함수의 seq_printf 호출에서 이 형식을 확인해볼 수 있습니다.

그러나 이는 수식이 아니고 출력 형식입니다. 실제 계산하는 과정을 확인하기 위해 get_avenrun 함수를 살펴보겠습니다.

exponentially decaying average of (R + D)

구체적인 계산식은 kernel/sched/loadavg.c의 get_avenrun 함수에서 확인할 수 있습니다.

해당 파일에 접근하면, 상단의 주석에서 load average의 계산 결과에 대한 설명을 참고할 수 있습니다.

The global load average is an exponentially decaying average of nr_running +
nr_uninterruptible.

Once every LOAD_FREQ:
    nr_active = 0;
    for_each_possible_cpu(cpu)
    nr_active += cpu_of(cpu)->nr_running + cpu_of(cpu)->nr_uninterruptible;
    avenrun[n] = avenrun[0] * exp_n + nr_active * (1 - exp_n)

위의 psuedo code를 보면 load average가 우리가 알고 있는 R, D 상태의 task 수를 적당히 가공한 수치임을 확인할 수 있습니다.

새로운 avenrun(avenrun[n])을 계산하기 위해 이전 시점의 avenrun(avenrun[0])을 활용하며, 이전 시점 avenrun[0]는 exp_n에 의해 지수적으로 감소하며[^2], 새로운 R, D 상태의 프로세스의 수를 의미하는 nr_active는 (1 - exp_n)에 의해 지수적으로 증가합니다.

[^2]: decay는 일반적으로 최근에 더욱 가중치를 주고 싶어 과거의 데이터의 가중치를 감소시키는 일종의 수학적 trick입니다.

$$
active \space process = R + D \
\space \
avenrun[n] = avenrun[0] \times exp + (R + D) \times (1 - exp)
$$

결국 단순히 R, D 상태의 task 수만으로 load average를 계산하는 것이 아니라
load average is an exponentially decaying average of nr_running + nr_uninterruptible. 라는 사실을 확인할 수 있습니다.

구체적으로 계산되는 코드를 찾기 위해 get_avenrun 함수를 살펴보겠습니다.

/**
 * get_avenrun - get the load average array
 * @loads:    pointer to dest load array
 * @offset:    offset to add
 * @shift:    shift count to shift the result left
 *
 * These values are estimates at best, so no need for locking.
 */
void get_avenrun(unsigned long *loads, unsigned long offset, int shift)
{
    loads[0] = (avenrun[0] + offset) << shift;
    loads[1] = (avenrun[1] + offset) << shift;
    loads[2] = (avenrun[2] + offset) << shift;
}

loads 배열에 avenrun 배열의 원소값을 조작해서 계산하는 것을 확인할 수 있습니다.
이제는 avenrun 배열이 초기화 되거나 활용되는 부분을 찾아야 합니다.
찾아보면, 동일 파일인 /kernel/sched/loadavg.c에서 avenrun 가 선언되었으며 calc_global_load 에서 계산되는 것을 확인할 수 있습니다.

// /kernel/sched/loadavg.c

/* Variables and functions for calc_load */
atomic_long_t calc_load_tasks;
unsigned long calc_load_update;
unsigned long avenrun[3]; // 여기에서 초기화 됩니다.

// /kernel/sched/loadavg.c

/*
 * calc_load - update the avenrun load estimates 10 ticks after the
 * CPUs have updated calc_load_tasks.
 *
 * Called from the global timer code.
 */
void calc_global_load(void)
{
    unsigned long sample_window;
    long active, delta;

    sample_window = READ_ONCE(calc_load_update);
    if (time_before(jiffies, sample_window + 10))
        return;

    /*
     * Fold the 'old' NO_HZ-delta to include all NO_HZ CPUs.
     */
    delta = calc_load_nohz_read();
    if (delta)
        atomic_long_add(delta, &calc_load_tasks);

    active = atomic_long_read(&calc_load_tasks);
    active = active > 0 ? active * FIXED_1 : 0;

    avenrun[0] = calc_load(avenrun[0], EXP_1, active);
    avenrun[1] = calc_load(avenrun[1], EXP_5, active);
    avenrun[2] = calc_load(avenrun[2], EXP_15, active);

    WRITE_ONCE(calc_load_update, sample_window + LOAD_FREQ);

    /*
     * In case we went to NO_HZ for multiple LOAD_FREQ intervals
     * catch up in bulk.
     */
    calc_global_nohz();
}

여기서 avenrun은 calc_load 함수에 의해 여러 값과 함께 계산이 되는 것으로 보입니다.

매크로 값은 아래와 같이 확인됩니다. 지수적 감소를 위한 exp_n 값으로 보입니다.

// /include/linux/sched/loadavg.h
#define EXP_1        1884        /* 1/exp(5sec/1min) as fixed-point */
#define EXP_5        2014        /* 1/exp(5sec/5min) */
#define EXP_15        2037        /* 1/exp(5sec/15min) */

active의 경우에는 앞서 살펴본 active process (R + D)의 갯수를 의미하는 것으로 보입니다.
active = atomic_long_read(&calc_load_tasks); 와 같은 함수의 형식으로 미루어보아, atomic_long_read는 atomic read를 지원하기 위한 함수로 보이며 calc_load_tasks가 핵심적인 값으로 보입니다.

conclusion : calc_load

최종적으로는 다음과 같이 계산되는 것을 확인할 수 있습니다.
주석에서 설명하던 exponential decay average를 계산하는 것을 확인할 수 있습니다.

// include/linux/sched/loadavg.h

calc_load(unsigned long load, unsigned long exp, unsigned long active)
{
    unsigned long newload;

    newload = load * exp + active * (FIXED_1 - exp);
    if (active >= load)
        newload += FIXED_1 - 1;

    return newload / FIXED_1;
}

load: 이전의 부하 평균 값입니다.
exp: 지수적 감쇠를 위한 계수로, 과거 데이터의 현재 값에 대한 영향을 조절합니다. (EXP_1, EXP_5, EXP_15)
active: 현재 활성화된 (실행 중 또는 실행 대기 중인) 프로세스의 수입니다.

newload = load * exp + active * (FIXED_1 - exp);
과거 부하 평균(load)에 지수적 감쇠 계수(exp)를 곱하고, 현재 활성화된 프로세스 수(active)에 1 - exp를 곱하여 두 값을 합산합니다. 여기서 FIXED_1은 고정 소수점 연산을 위한 상수입니다.[^3]

if (active >= load) newload += FIXED_1 - 1;
만약 현재 활성화된 프로세스 수가 이전 부하 평균보다 크거나 같은 경우, newload에 추가적인 값(FIXED_1-1)을 더합니다. 이는 부하가 증가하는 상황에서 부하 평균을 보다 빠르게 반응하도록 하는 조정입니다.

return newload / FIXED_1;
마지막으로, 계산된 새로운 부하 평균(newload)을 FIXED_1로 나누어 반환합니다. 이는 고정 소수점 연산을 실제 부동 소수점 값으로 변환하는 단계입니다.

[^3]: FIXED_1이 왜 고정 소수점 연산을 위한 상수인가?

고정 소수점은 비트 중 일부를 소수 부분에 할당합니다. 그래서 얼마나 많은 비트를 소수 부분에 할당할 것인지를 결정해야 합니다. 이를 위해 FSHIFT라는 상수를 사용합니다.

구체적인 값은 다음과 같습니다.

```c
// include/linux/sched/loadavg.h
#define FSHIFT        11        /* nr of bits of precision */
#define FIXED_1        (1<<FSHIFT)    /* 1.0 as fixed-point */
```

FIXED_1는 1.0을 고정 소수점으로 표현한 것입니다. 전체 비트에서 소수에 할당된 부분을 제외하고 left shift를 하여 1.0을 표현합니다.

따라서, 우리가 부동 소수점으로 5.0을 표현했고 이것은 고정 소수점으로 변환하고 싶다면 5.0 \* FIXED_1을 하면 됩니다. 반대로 고정 소수점을 부동 소수점으로 변환하고 싶다면 5.0 / FIXED_1을 하면 됩니다.

kernel study 02: top을 통해 확인할 수 있는 프로세스 정보들

DarrenKwonDev — Thu, 28 Dec 2023 04:34:04 +0900

https://darrenkwondev.github.io/posts/2023-12-27_kernel_study_02.md/

아래에서 더 깔끔하게 읽을 수 있습니다.

kernel study 02: top을 통해 확인할 수 있는 프로세스 정보들 | darrenkwon.dev blog

단순한 사용 방법은 리눅스 top 정리 및 설명 을 참고하는 것이 좋습니다. 또한, 표현된 각 column 외에도 다른 metric은 man 페이지를 통해 확인하실 수 있습니다. 여기서는 top을 통해 살펴볼 수 있는

darrenkwondev.github.io

top

top -hv|-bcEeHiOSs1 -d secs -n max -u|U user -p pids -o field -w [cols]

단순한 사용 방법은 리눅스 top 정리 및 설명을 참고하는 것이 좋습니다.
또한, 표현된 각 column 외에도 다른 metric은 man 페이지를 통해 확인하실 수 있습니다.

여기서는 top을 통해 살펴볼 수 있는 세부적인 여러 process 관련 정보들을 살펴보도록 하겠습니다.

{{< box info >}}
task

리눅스에서 프로세스와 스레드는 개념적으로 구분되지만, 내부적으로는 모두 '태스크'로 관리됩니다.
리눅스 커널은 프로세스와 스레드를 동일한 기본 구조인 'task_struct'를 사용하여 표현합니다.

sched.h
{{< /box >}}

top의 개선판들

htop, vtop, gtop, gotop

memory

virtual memory (메모리 가상화)

A program selects a memory location using a virtual address. The processor translates this into a physical address and finally the memory controller selects the RAM chip corresponding to that address.

즉, 프로세스는 virtual address를 통해 메모리를 다루지만, 실제 physical address로의 변환은 processor가 수행하는 셈입니다.[^2]

정리하자면,

virtual address(가상 주소): 프로세스가 참조하는 주소
physical address(물리 주소): 실제 메모리 주소

이며, 특정 가상 주소가 어느 물리 주소에 매핑되어있는지 변환하는 과정을 수행하는 과정은 cpu(processor) 내의 MMU(Memory Management Unit)가 수행합니다. MMU의 역할을 다시 정리하자면, CPU에에서 컴파일된 코드 실행시 가상 주소 메모리 접근이 필요할 때 해당 주소를 물리 주소 값으로 변환해주는 하드웨어 장치입니다.

가상 메모리 서브시스템의 실제 구현 세부 사항을 직접 확인해보고 싶다면 lwn의 관련 아티클^1 을 참고할 수 있습니다.

[^2]: 이러한 가상(logical, virtual)과 물리(physical)의 분리는 메모리 뿐만 아니라 스토리지, 네트워크 등의 분야에서 자주 접하게 되는 패턴입니다. 물리를 감싸는 하나의 추상화된 레이어를 제공하여 파편화 해결, 공유화 등의 이점을 제공할 수 있습니다.

Linux Memory Types

man 페이지에 따르면 프로세스가 소유한 메모리는 다음 4가지로 분류될 수 있습니다. 지금 당장 top의 출력물을 이해하는데 필요한 내용은 아니지만, 이후에 프로세스의 메모리 사용량을 살펴볼 때 필요한 내용이므로 간단히 정리해보도록 하겠습니다.

                             Private | Shared
                         1           |          2
    Anonymous  . stack               |
               . malloc()            |
               . brk()/sbrk()        | . POSIX shm*
               . mmap(PRIVATE, ANON) | . mmap(SHARED, ANON)
              -----------------------+----------------------
               . mmap(PRIVATE, fd)   | . mmap(SHARED, fd)
  File-backed  . pgms/shared libs    |
                         3           |          4

위 사분면에 근거하여, top의 각 세부 정보들을 대략적으로 설명하면 다음과 같습니다.

우리가 흔히 메모리 영역을 heap, stack, data, code로 분류하곤 합니다. 이에 대해 관련 있는 내용은 다음과 같습니다.

stack : quadrant 1에 해당합니다. 컴파일 타임에 크기가 결정됩니다.
heap : quadrant 1에 해당하되 mmap을 통해 할당된 경우에도 속합니다. 우리가 흔히 쓰는 malloc이 qudrant 1에 속함을 확인해볼 수 있습니다.
CODE : the `pgms' portion of quadrant 3
DATA : the entire quadrant 1 portion of VIRT plus all explicit mmap file-backed pages of quadrant 3

top의 출력물에서 관련있는 정보는 다음과 같습니다.

VIRT : everything in-use and/or reserved (all quadrants)
SHR : subset of RES (excludes 1, includes all 2 & 4, some 3)
RES : anything occupying physical memory which, beginning with Linux-4.5, is the sum of the following three fields:
- RSan - quadrant 1 pages, which include any
- former quadrant 3 pages if modified
- RSfd - quadrant 3 and quadrant 4 pages
- RSsh - quadrant 2 pages

memory commit 과정과 VIRT, RES, SHR

이제 종합적으로 프로세스가 처음 생성될 때 메모리를 할당 받는 과정인 memory commit을 살펴보겠습니다.

가상 메모리 할당 (VIRT): 프로세스가 생성될 때, 커널은 해당 프로세스에 대해 가상 메모리 공간(VIRT)을 할당합니다. 이 공간은 프로세스가 사용할 수 있는 메모리의 최대 범위를 나타내지만, 처음에는 실제 물리 메모리에 할당되지 않습니다. 이것은 메모리를 효율적으로 관리하고, 실제로 필요할 때만 물리 메모리를 사용하도록 하는 것입니다.

실제 메모리 할당과 페이지 폴트 (RES): 프로세스가 운영되는 동안, 특히 쓰기 작업이 시작될 때, 가상 메모리의 일부가 실제로 필요하게 됩니다. 이때 '페이지 폴트(page fault)'가 발생합니다. 페이지 폴트는 매핑된 물리적 메모리가 페이지 테이블에 존재하지 않을 때 발생하는 것으로, 이를 통해 커널은 해당 가상 메모리 공간에 대응하는 물리 메모리(RES)를 할당하게 됩니다.

공유 메모리 (SHR): 공유 라이브러리와 같이 여러 프로세스에서 공유되는 메모리 영역은 SHR(공유 메모리)로 표시됩니다. 이러한 메모리는 다른 프로세스와 공유되는 물리적 메모리 주소를 가리키며, 각 프로세스의 가상 메모리 공간을 통해 동일한 물리적 메모리 주소를 참조하게 됩니다. 이는 메모리 사용의 효율성을 높이고, 중복을 방지하는 역할을 합니다.

VIRT, RES, SHR에 대한 man 페이지 설명

1.  VIRT  --  Virtual Memory Size (KiB)
The total amount of virtual memory used by the task.  It includes all code, data and shared libraries plus  pages  that  have
been swapped out and pages that have been mapped but not used.

22. RES  --  Resident Memory Size (KiB)
A subset of the virtual address space (VIRT) representing the non-swapped physical memory a task is currently using.   It  is
also the sum of the RSan, RSfd and RSsh fields.
It  can  include  private anonymous pages, private pages mapped to files (including program images and shared libraries) plus
shared anonymous pages.  All such memory is backed by the swap file represented separately under SWAP.
Lastly, this field may also include shared file-backed pages which, when modified, act as a dedicated swap file and thus will
never impact SWAP.

30. SHR  --  Shared Memory Size (KiB)
A subset of resident memory (RES) that may be used by other processes.  It will include shared  anonymous  pages  and  shared
file-backed pages.  It also includes private pages mapped to files representing program images and shared libraries.

memory overcommit

프로세스가 요구하는 메모리의 양은 결국 물리 메모리 공간의 한계를 넘을 수 없다.
넘게 된다면 커널 파라미터인 vm.overcommit_memory의 정의에 따라 커널이 처리한다.^1346

sysctl vm.overcommit_memory # can be 0, 1, 2

process status

맨 페이지를 통해 좀 더 자세한 내용을 살펴보자.

29. S  --  Process Status
    The status of the task which can be one of:
        D = uninterruptible sleep
        I = idle
        R = running
        S = sleeping
        T = stopped by job control signal
        t = stopped by debugger during trace
        Z = zombie

D (uninterruptible sleep)
i/o를 대기하고 있는 프로세스를 의미합니다. 프로세스가 D 상태라는 것은, run queue에서 나와 wait queue에서 대기하게 됨을 말합니다.
만약 i/o 작업이 완료되면 (예를 들어, read/write가 완료되면) 프로세스는 다시 R 상태가 됩니다.
R
실제로 cpu를 사용하고 있는 프로세스를 의미합니다.
S (interruptible sleep)
sleep 상태입니다. D와 다른 점은,
i/o가 아닌 단순 sleep이나 콘솔의 입력을 기다리는 경우에는 S 상태가 됩니다.
T, t
프로세스를 디버거, strace 등으로 중단시킨 상태를 의미합니다.
Z
좀비 프로세스입니다. 종료되었지만, 부모 프로세스에 의해 아직 회수(리소스 해제)되지 않은 프로세스입니다. 부모 프로세스가 자식 프로세스의 exit code(exit(int) 혹은 main return(int))을 요청해야 합니다.

보통 좀비 프로세스를 제거하기 위해서 child process의 종료 시그널을 받아 처리하는 방식을 사용하곤 합니다. 아래는 간략한 예시입니다.

void handle_child(int sig) {
    if (sig == SIGCHLD) {
        int status;

        // 성공시 종료된 ps의 pid반환.
        // 특정 pid가 아닌 -1을 전달함으로써 임의의 자식 프로세스 종료를 처리함.
        pid_t id = waitpid(-1, &status, WNOHANG); // non blocking
        if (WIFEXITED(status)) {
            printf("remove ps id : %d\n", id);
            printf("child send : %d\n", WEXITSTATUS(status));
        }
    }
}

int main(int argc, char* argv[]) {
    pid_t pid = 0;

    // signal handling
    struct sigaction act;
    act.sa_handler = handle_child;
    sigemptyset(&act.sa_mask);
    act.sa_flags = 0;
    sigaction(SIGCHLD, &act, 0);

    ... 생략

    return 0;
}

PR, NI

run queue에 잡힌 task들은 PR(priority)와 NI(nice)에 따라 스케쥴러의 알고리즘에 의해 cpu를 할당받게 됩니다.

실제로 PR이 낮으면 먼저 dispatcher가 cpu에게 처리해줄 것을 요청한다.
NI는 PR의 조정값으로, 우선순위는 PR + NI로 결정된다.

예를 들어 process A의 PR: 10, NI: 0, process B의 PR: 10, NI: 5라면,
process A가 10, process B가 15의 우선순위를 갖게 된다.
따라서 process A가 먼저 cpu를 할당받게 된다.

renice

Alters the scheduling priority/niceness of one or more running processes.
Niceness values range from -20 (most favorable to the process) to 19 (least favorable to the process).
More information: https://manned.org/renice.

# Change priority of a running process:
renice -n niceness_value -p pid

# Change priority of all processes owned by a user:
renice -n niceness_value -u user

# Change priority of all processes that belong to a process group:
renice -n niceness_value --pgrp process_group

kernel study 01: 시스템 구성 정보 확인하기

DarrenKwonDev — Wed, 27 Dec 2023 02:34:47 +0900

https://darrenkwondev.github.io/posts/2023-12-27_kernel_study_01.md/kernel_study_01/

kernel study 01: 시스템 구성 정보 확인하기 | darrenkwon.dev blog

커널 이름, 호스트 이름, 커널 버전, 커널 릴리즈, 운영 체제, 하드웨어 이름(아키텍처) 등 시스템 정보를 출력하는 도구 5.15.0-91-generic 커널을 사용 중임을 확인할 수 있다. 커널의 메시지 버퍼의

darrenkwondev.github.io

위에서 더 깔끔하게 읽을 수 있겠습니다.

---

+++

title = 'kernel study 01: 시스템 구성 정보 확인하기'

date = 2023-12-27T00:02:35+09:00

math = true

toc = true

bold = true

draft = false

tags = ["linux", "system engineering", "korean"]

+++

based on Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-91-generic aarch64) VM

## 커널 정보 확인

### uname (UNIX name)

커널 이름, 호스트 이름, 커널 버전, 커널 릴리즈, 운영 체제, 하드웨어 이름(아키텍처) 등 시스템 정보를 출력하는 도구

```

# uname -a

Linux drkup 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:29:11 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

```

5.15.0-91-generic 커널을 사용 중임을 확인할 수 있다.

### dmesg (display message)

커널의 메시지 버퍼의 내용을 출력하는 도구.

kernel이 부팅되면서 출력했된 내용을 살펴보겠습니다.

```

# sudo dmesg | grep -i kernel | more

# kernel 문자열을 포함한 로그만 출력해보았다.

# 좌측 괄호 [] 안은 시스템 부팅 이후 경과한 시간을 초 단위를 표현한 것이다.

# 커널 코드에 패치 적용 (시스템이 부팅되는 과정)

[ 0.000000] alternatives: patching kernel code

# 커널 파라미터. BOOT_IMAGE, root, ro 등이 보인다.

[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-5.15.0-91-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro

# 주어진 커널 파라미터이지만 인식하지 못하는 파라미터는 user space로 전달된다.

[ 0.000000] Unknown kernel command line parameters "BOOT_IMAGE=/vmlinuz-5.15.0-91-generic", will be passed to user space.

# 커널이 인식하는 메모리 정보.

# 시스템에 4194304K 메모리가 존재하며 3860508K가 사용 가능하다.

[ 0.000000] Memory: 3860508K/4194304K available (17280K kernel code, 4576K rwdata, 13928K rodata, 9600K init, 1194K bss, 301028K reserved

, 32768K cma-reserved)

# 직접 메모리 액세스(DMA)에 사용되는 사전 할당된 메모리 풀 관련 로그

# CPU를 거치지 않고 메모리와 하드웨어 장치 간에 데이터를 직접 전송하기 위해 필요합니다.

[ 0.084903] DMA: preallocated 512 KiB GFP_KERNEL pool for atomic allocations

[ 0.085653] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations

[ 0.086177] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations

# 커널이 로드한 X.509 인증서 관련 로그

[ 0.744737] Loaded X.509 cert 'Build time autogenerated kernel key: a3ee82ff8d989103803e60e521b19f3fabe02ee9'

[ 0.746343] Loaded X.509 cert 'Canonical Ltd. Kernel Module Signing: 88f752e560a1e0737e31163a466ad7b70a850c19'

[ 0.797094] Loaded X.509 cert 'Build time autogenerated kernel key: a3ee82ff8d989103803e60e521b19f3fabe02ee9'

# 시스템 부팅 하면서 사용했던 메모리를 반환

[ 0.802006] Freeing unused kernel memory: 9600K

# systemd 작업들.

[ 3.234080] systemd[1]: Listening on udev Kernel Socket.

[ 3.236727] systemd[1]: Mounting Kernel Debug File System...

[ 3.241096] systemd[1]: Mounting Kernel Trace File System...

[ 3.276186] systemd[1]: Starting Load Kernel Module chromeos_pstore...

[ 3.278110] systemd[1]: Starting Load Kernel Module configfs...

[ 3.283414] systemd[1]: Starting Load Kernel Module drm...

[ 3.285204] systemd[1]: Starting Load Kernel Module efi_pstore...

[ 3.290713] systemd[1]: Starting Load Kernel Module fuse...

[ 3.298218] systemd[1]: Starting Load Kernel Module pstore_blk...

[ 3.302885] systemd[1]: Starting Load Kernel Module pstore_zone...

[ 3.305147] systemd[1]: Starting Load Kernel Module ramoops...

[ 3.311579] systemd[1]: Starting Load Kernel Modules...

[ 3.313671] systemd[1]: Starting Remount Root and Kernel File Systems...

```

### /boot/config-$(uname -r)

커널의 컴파일 옵션을 확인해보겠습니다. 특정 옵션이 활성화 되어 있어야만 사용할 수 있는 기능이 존재합니다.

예를 들어 ftrace를 사용하기 위해서는 CONFIG_FTRACE 옵션이 활성화 되어 있어야 합니다.

```

#cat /boot/config-$(uname -r) | head -n 10

# 너무 많은 옵션이 존재하니 앞의 10줄 정도만 출력해보았습니다.

# Automatically generated file; DO NOT EDIT.

# Linux/arm64 5.15.0-91-generic Kernel Configuration

CONFIG_CC_VERSION_="gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0"

CONFIG_CC_IS_GCC=y

CONFIG_GCC_VERSION=110400

CONFIG_CLANG_VERSION=0

CONFIG_AS_IS_GNU=y

CONFIG_AS_VERSION=23800

```

## dmidecode (dmi : Desktop Management Interface)

하드웨어 정보를 보여주는 명령어입니다. 이 명령어는 시스템의 BIOS, 시스템 보드, 프로세서, 메모리 등과 같은 다양한 컴포넌트에 대한 상세한 정보를 제공합니다.

가능한 타입을 나열하면 아래와 같습니다.

```

Valid type keywords are:

bios

system

baseboard

chassis

processor

memory

cache

connector

slot

```

### dmidecode -t bios

BIOS(Basic Input/Output System)를 확인해보겠습니다.

```

# dmidecode -t bios

# UTM VM에서 실행하여 흔히 보이는 vendor가 아닌 UEFI 환경임을 확인할 수 있습니다.

# dmidecode 3.3

Getting SMBIOS data from sysfs.

SMBIOS 3.0.0 present.

Handle 0x0000, DMI type 0, 26 bytes

BIOS Information

Vendor: EFI Development Kit II / OVMF

Version: 0.0.0

Release Date: 02/06/2015

Address: 0xE8000 # bios가 메모리 상에서 위치한 시작 주소

Runtime Size: 96 kB # bios run time의 크기입니다.

ROM Size: 64 kB

Characteristics:

BIOS characteristics not supported

Targeted content distribution is supported

UEFI is supported

System is a virtual machine

BIOS Revision: 0.0

```

### dmidecode -t system

시스템 관련 정보를 출력해보겠습니다. 컴퓨터를 구성하는 다양한 하드웨어의 모델명 등을 확인할 수 있습니다.

```

# dmidecode -t system

# VM이라서 에뮬레이터인 QEMU를 사용하고 있음을 확인할 수 있습니다.

# dmidecode 3.3

Getting SMBIOS data from sysfs.

SMBIOS 3.0.0 present.

Handle 0x0100, DMI type 1, 27 bytes

System Information

Manufacturer: QEMU

Product Name: QEMU Virtual Machine

Version: virt-7.2

Serial Number: Not Specified

UUID: <omit>

Wake-up Type: Power Switch

SKU Number: Not Specified

Family: Not Specified

Handle 0x2000, DMI type 32, 11 bytes

System Boot Information

Status: No errors detected

```

## cpu[^1]

[^1]: cpu의 개략적인 내용은 [cpu.land](https://cpu.land/)의 문서를 확인해보는 것이 좋습니다.

### /proc/cpuinfo

```

# cat /proc/cpuinfo

processor : 0

BogoMIPS : 48.00

Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint

CPU implementer : 0x00

CPU architecture: 8

CPU variant : 0x0

CPU part : 0x000

CPU revision : 0

(omit)

```

### dmidecode -t processor

cpu(processor) 정보를 출력해보겠습니다.

자주 출력해보는 내용이기 때문에 가상 머신이 아닌 타 기기에서 출력된 내용물을 가지고 설명해보겠습니다.

장착된 cpu가 1개라고 인식되기 때문에 하나의 cpu 정보만 출력되었습니다. 만약 motherboard의 소켓에 여러 cpu를 장착했다면, 해당 갯수만큼 출력될 것입니다.

흔히 물리적 cpu 코어의 갯수와 논리적 cpu 코어의 갯수를 헷갈리는데 해당 출력을 통해 명확히 구분할 수 있습니다. Socket Designation은 곧 cpu가 mother board에 장착된 소켓의 위치이며, Core Count는 장착된 하나의 cpu가 소유한 컴퓨팅 코어를 의미합니다. 아래 출력물을 기준으로 설명하자면, 물리적으로 cpu는 2개가 소켓에 장착되어 있으며 각각 8개의 코어를 가지고 있으며 하이퍼 쓰레딩이 적용되어 있어 하나의 코어당 2개 이상의 thread가 존재하는 것으로 확인됩니다.

```

# dmidecode -t processor

# dmidecode 3.3

Getting SMBIOS data from sysfs.

SMBIOS 3.2.0 present.

Handle 0x0400, DMI type 4, 48 bytes

Processor Information

Socket Designation: CPU 0 # cpu가 장착된 소켓의 이름입니다. MB에 cpu를 장착할 때 사용하는 소켓의 이름과 동일합니다.

Type: Central Processor # cpu임을 나타냅니다.

Family: Xeon

Manufacturer: Intel

ID: C3 06 03 00 FF FB EB BF

Version: Intel(R) Xeon(R) CPU E5-2600 v4

Voltage: 1.2 V

External Clock: 100 MHz

Max Speed: 3000 MHz

Current Speed: 3000 MHz

Status: Populated, Enabled

Upgrade: Socket LGA 2011

L1 Cache Handle: 0x0700

L2 Cache Handle: 0x0701

L3 Cache Handle: 0x0702

Serial Number: Not Specified

Asset Tag: Not Specified

Part Number: Not Specified

Core Count: 8 # cpu가 소유한 물리적 core 갯수를 의미합니다.

Core Enabled: 8

Thread Count: 16 # 일반적으로 하이퍼스레딩 또는 다중 스레딩 기술이 적용된 경우, 물리적 코어 수보다 스레드 수가 더 많습니다.

Characteristics:

64-bit capable

Multi-Core

Hardware Thread

# 다른 소켓에 장착된 cpu의 정보를 출력합니다. 해당 컴퓨터가 2개의 cpu를 장착하고 있음을 의미합니다.

Handle 0x0401, DMI type 4, 48 bytes

Processor Information

Socket Designation: CPU 1

Type: Central Processor

Family: Xeon

Manufacturer: Intel

ID: C3 06 03 00 FF FB EB BF

Version: Intel(R) Xeon(R) CPU E5-2600 v4

Voltage: 1.2 V

External Clock: 100 MHz

Max Speed: 3000 MHz

Current Speed: 3000 MHz

Status: Populated, Enabled

Upgrade: Socket LGA 2011

L1 Cache Handle: 0x0703

L2 Cache Handle: 0x0704

L3 Cache Handle: 0x0705

Serial Number: Not Specified

Asset Tag: Not Specified

Part Number: Not Specified

Core Count: 8

Core Enabled: 8

Thread Count: 16

Characteristics:

64-bit capable

Multi-Core

Hardware Thread

```

### lscpu

cpu와 관련된 정보를 출력하는 명령어입니다. dmidecode와 비슷한 역할을 하지만, 더 간단하게 출력해줍니다.

특히, NUMA와 관련된 정보를 출력해주는 점이 차이점입니다.

```

# lscpu

Architecture: aarch64

CPU op-mode(s): 64-bit

Byte Order: Little Endian

CPU(s): 8

On-line CPU(s) list: 0-7

Vendor ID: 0x00

Model: 0

Thread(s) per core: 1

Core(s) per socket: 8

Socket(s): 1

Stepping: 0x0

BogoMIPS: 48.00

Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp s

ha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint

NUMA:

NUMA node(s): 1

NUMA node0 CPU(s): 0-7

Vulnerabilities:

Gather data sampling: Not affected

Itlb multihit: Not affected

L1tf: Not affected

Mds: Not affected

Meltdown: Not affected

Mmio stale data: Not affected

Retbleed: Not affected

Spec rstack overflow: Not affected

Spec store bypass: Vulnerable

Spectre v1: Mitigation; __user pointer sanitization

Spectre v2: Not affected

Srbds: Not affected

Tsx async abort: Not affected

```

## memory

### /proc/meminfo

메모리 정보를 출력하는 명령어입니다. 메모리의 총 용량, 사용량, 사용 가능한 용량 등을 확인할 수 있습니다.

```

# cat /proc/meminfo

MemTotal: 4004640 kB

MemFree: 1628216 kB

MemAvailable: 3582652 kB

Buffers: 62432 kB

Cached: 1957112 kB

SwapCached: 0 kB

Active: 623540 kB

Inactive: 1451744 kB

Active(anon): 1332 kB

```

### free

```

# free

total used free shared buff/cache available

Mem: 4004640 225444 1628468 5380 2150728 3582876

Swap: 3001340 0 3001340

```

total = used + free + buff/cached

- total : Total installed memory (MemTotal and SwapTotal in /proc/meminfo)

- used : Used memory (= total - free - buffers - cache)

- 진짜로 사용되고 있는 영역이 아니라, buff/cache를 제외한 메모리를 말합니다.

- free : Unused memory (MemFree and SwapFree in /proc/meminfo)

- buff/cache = 디스크에 있는 파일이 메모리에 올라와 유지된 것들. 사실상 쓰고 있지만 used로 잡히지가 않음

- buffers : Memory used by kernel buffers (Buffers in /proc/meminfo)

- 파일 정보, 파일의 메타 데이터를 의미합니다.

- cache : Memory used by the page cache and slabs (Cached and SReclaimable in /proc/meminfo)

- 파일의 실제 내용을 저장되는데 사용됩니다.

- 예를 들면 동영상 파일이 메모리에 올라와 있다면 buffer는 작겠지만 cache는 클 것이라 예측할 수 있다.

- shared : Memory used (mostly) by tmpfs (Shmem in /proc/meminfo)

- available : Estimation of how much memory is available for starting new applications, without swapping.

- 어떤 프로세스가 만들어진다면 메모리를 사용할 때 최대 어디까지 사용할 수 있음?

- 보통 buff/cache + free 정도임.

### dmidecode -t memory

dmidecode의 메모리 정보 출력물을 통해서, 메모리를 Physical Memory Array와 Memory Device로 구분하여 출력합니다.

```

# dmidecode -t memory

# dmidecode 3.3

Getting SMBIOS data from sysfs.

SMBIOS 3.0.0 present.

Handle 0x1000, DMI type 16, 23 bytes

Physical Memory Array

Location: Other

Use: System Memory

Error Correction Type: Multi-bit ECC

Maximum Capacity: 4 GB

Error Information Handle: Not Provided

Number Of Devices: 1

Handle 0x1100, DMI type 17, 40 bytes

Memory Device

Array Handle: 0x1000

Error Information Handle: Not Provided

Total Width: Unknown

Data Width: Unknown

Size: 4 GB

Form Factor: DIMM

Set: None

Locator: DIMM 0

Bank Locator: Not Specified

Type: RAM

Type Detail: Other

Speed: Unknown

Manufacturer: QEMU

Serial Number: Not Specified

Asset Tag: Not Specified

Part Number: Not Specified

Rank: Unknown

Configured Memory Speed: Unknown

Minimum Voltage: Unknown

Maximum Voltage: Unknown

Configured Voltage: Unknown

```

## disk

### df (disk free)

각 파일 시스템이 마운트 된 곳과 용량을 출력합니다.

/dev/mapper/ubuntu--vg-ubuntu--lv, /dev/vda1, /dev/vda2 3개의 파일 시스템이 확인됩니다.

마운트된 경로를 보니 vda1, vda2는 부트 파티션으로 사용되고 있고, ubuntu--vg-ubuntu--lv는 루트 파티션으로 사용되고 있음을 확인할 수 있습니다.

VM 위의 파일 시스템이기 때문에 vda로 시작하는 이름을 가지고 있습니다. 일반적으로는 hda나 sda로 시작하는 이름을 가지고 있습니다.

tmpfs 는 임시 파일 시스템을 의미합니다.

```

# df -h (human readable)

Filesystem Size Used Avail Use% Mounted on

tmpfs 392M 1.4M 390M 1% /run

/dev/mapper/ubuntu--vg-ubuntu--lv 15G 7.0G 6.5G 52% /

tmpfs 2.0G 0 2.0G 0% /dev/shm

tmpfs 5.0M 0 5.0M 0% /run/lock

/dev/vda2 2.0G 129M 1.7G 8% /boot

/dev/vda1 1.1G 6.4M 1.1G 1% /boot/efi

tmpfs 392M 4.0K 392M 1% /run/user/1000

```

### lsblk (list block devices)

블록 장치(디스크, 파티션, 논리 볼륨 등)에 대한 정보를 출력합니다.

특히, RAID 구성 여부를 확인할 수 있습니다.

```

# lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS

loop0 7:0 0 59.2M 1 loop /snap/core20/1977

loop1 7:1 0 109.6M 1 loop /snap/lxd/24326

loop2 7:2 0 46.4M 1 loop /snap/snapd/19459

loop3 7:3 0 35.5M 1 loop /snap/snapd/20298

sr0 11:0 1 1024M 0 rom

vda 252:0 0 32G 0 disk

├─vda1 252:1 0 1G 0 part /boot/efi

├─vda2 252:2 0 2G 0 part /boot

└─vda3 252:3 0 28.9G 0 part

└─ubuntu--vg-ubuntu--lv 253:0 0 14.5G 0 lvm /

```

MAJ:MIN: major, minor number. 커널이 해당 디스크를 식별하는 데 사용하는 고유 번호입니다.

RM: 디스크의 제거 가능 여부

RO: 읽기 전용 여부

TYPE: 디스크의 타입. lvm(logical volume manager)를 사용하고 있음을 확인할 수 있습니다. RAID로 구성여부도 출력됩니다.

MOUNTPOINTS: 마운트된 경로

```

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

sda 8:0 0 1TB 0 disk

├─sda1 8:1 0 512M 0 part /boot/efi

├─sda2 8:2 0 2GB 0 part [SWAP]

└─sda3 8:3 0 997.5G 0 part

└─md0 9:0 0 1.9T 0 raid1 /

sdb 8:16 0 1TB 0 disk

├─sdb1 8:17 0 512M 0 part

├─sdb2 8:18 0 2GB 0 part

└─sdb3 8:19 0 997.5G 0 part

└─md0 9:0 0 1.9T 0 raid1 /

```

위 예시에서 "sda"와 "sdb" 디스크는 RAID1으로 구성되었습니다. "md0"은 RAID 레이드 장치를 나타내며 "/dev/md0"는 RAID로 구성된 볼륨을 나타냅니다. RAID 구성은 여러 디스크의 복제 또는 데이터 분산을 허용하므로 "md0"의 하위 항목으로 "sda3"와 "sdb3"이 나타납니다.

## network (네트워크 카드)

### 네트워크 카드(NIC) 확인하기

lspci 명령어는 PCI 버스를 통해 연결된 장치들의 정보를 출력합니다.

여기서는 네트워크와 관련된 정보만을 grep하기 위해 grep 명령어를 사용하였습니다.

구체적으로, 서버가 사용하는 네트워크 카드(NIC)를 확인할 수 있습니다.

```

# lspci | grep -i ether

00:01.0 Ethernet controller: Red Hat, Inc. Virtio network device

```

### ip로 network interface 확인

ifconfig 보다 ip 사용을 권장함. ifconfig는 유지 보수가 끝났으나 ip는 리눅스 커널과 같이 개발되며 지속적으로 유지보수되고 있음.

```

ip address # ip a로만 입력 가능

ip link # 네트워크 인터페이스 확인

ip neigh # ARP 테이블 (mac 주소) 확인하기

```

해당 글에서는 하드웨어적인 측면에서 살펴봐야하므로 ip 명령어에 대한 설명은 네트워크 인터페이스의 목록을 확인하는 것 정도로 마치겠습니다.

```

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000

link/ether 1e:6f:22:b0:70:1e brd ff:ff:ff:ff:ff:ff

inet 192.168.64.4/24 metric 100 brd 192.168.64.255 scope global dynamic enp0s1

valid_lft 72571sec preferred_lft 72571sec

inet6 fd1d:e88a:d67e:2671:1c6f:22ff:feb0:701e/64 scope global dynamic mngtmpaddr noprefixroute

valid_lft 2591943sec preferred_lft 604743sec

inet6 fe80::1c6f:22ff:feb0:701e/64 scope link

valid_lft forever preferred_lft forever

```

루프팩 인터페이스를 제외하고, enp0s1 인터페이스, en(이더넷), po(포트), s1(슬롯1)을 의미합니다.

### ethtool

위에서 확인한 네트워크 인터페이스의 구체적인 정보를 확인해볼 수 있습니다.

안타깝게도 가상 머신에서는 정상적인 값을 출력하지 않으므로 타 기기의 출력물을 살펴보겠습니다.

Supported link modes는 네트워크 카드가 지원하는 연결 모드를 의미합니다.

Advertised link modes는 네크워크 상 다른 장치와 연결 할 때 사용할 수 있는 연결 모드를 의미합니다.

해당 네트워크 카드가 지원하는 연결 모드와 속도를 확인해보겠습니다.

Half Duplex and Full Duplex

Half Duplex는 데이터가 한 번에 한 방향으로만 전송될 수 있음을 의미합니다.

Full Duplex는 데이터가 동시에 양방향으로 전송될 수 있음을 의미합니다.

- 10baseT/Half 10baseT/Full: 10 Mbps 속도의 Half Duplex와 Full Duplex 연결을 지원합니다.

- 100baseT/Half와 100baseT/Full: 각각 100 Mbps의 Half Duplex와 Full Duplex 연결을 지원합니다.

- 1000baseT/Full: 1000 Mbps (1 Gbps) 속도의 Full Duplex 연결을 지원합니다.

```

Settings for enp0s1:

Supported ports: [ TP ]

Supported link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Full

Supported pause frame use: No

Supports auto-negotiation: Yes

Advertised link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Full

Advertised pause frame use: No

Advertised auto-negotiation: Yes

Link partner advertised link modes: Not reported

Link partner advertised pause frame use: No

Link partner advertised auto-negotiation: No

Speed: 1000Mb/s # 현재 속도

Duplex: Full # duplex 지원

Port: Twisted Pair

PHYAD: 0

Transceiver: internal

Auto-negotiation: on

MDI-X: off (auto)

Supports Wake-on: pumbg

Wake-on: g

Current message level: 0x00000007 (7)

drv probe link

Link detected: yes # 정상적으로 연결되었음을 의미합니다.

```

### ethtool -g (ring buffer)

NIC의 버퍼 공간인 ring buffer의 크기를 확인해볼 수 있습니다.

패킷이 전달되면 ring buffer에 우선 복사된 후 커널에 의해 처리됩니다.

ring buffer가 너무 작다면 자주 커널에 의해 처리되어야 하므로 성능 저하가 발생할 수 있습니다.

관습적으로 pre-set maximums와 같게 hardware settings을 맞춰야 합니다.

수정을 원한다면 -G 플래그를 통해 수정할 수 있습니다.

```

# ethtool -g enp0s1

Ring parameters for enp0s1:

Pre-set maximums:

RX: 256

RX Mini: n/a

RX Jumbo: n/a

TX: 256

Current hardware settings:

RX: 256

RX Mini: n/a

RX Jumbo: n/a

TX: 256

```

### ethtool -k

NIC 옵션을 확인할 수 있습니다.

tcp-offload 기능을 통해 mtu 이상의 크기를 가진 패킷의 분할 작업을 cpu가 아닌 NIC가 처리하도록 할 수 있습니다. 그러나 네트워크 대역폭이 높은 서버와 같이 특정 환경에서는 불특정한 패킷 유실이 발생할 수 있어 off 시키곤 합니다.

```

# ethtool -k enp0s1 | head -n 10

Features for enp0s1:

rx-checksumming: off [fixed]

tx-checksumming: off

tx-checksum-ipv4: off [fixed]

tx-checksum-ip-generic: off [fixed]

tx-checksum-ipv6: off [fixed]

tx-checksum-fcoe-crc: off [fixed]

tx-checksum-sctp: off [fixed]

scatter-gather: off

tx-scatter-gather: off [fixed]

```

### ethtool -i

NIC의 커널 드라이버 정보를 확인할 수 있습니다.

```

ethtool -i enp0s1

driver: virtio_net

version: 1.0.0

firmware-version:

expansion-rom-version:

bus-info: 0000:00:01.0

supports-statistics: yes

supports-test: no

supports-eeprom-access: no

supports-register-dump: no

supports-priv-flags: no

```

게임 엔진 제작하기

DarrenKwonDev — Tue, 26 Dec 2023 01:57:25 +0900

https://github.com/DarrenKwonDev/simple_2d_game_engine

GitHub - DarrenKwonDev/simple_2d_game_engine: SDL-based 2D game engine using event system and ECS pattern

SDL-based 2D game engine using event system and ECS pattern - GitHub - DarrenKwonDev/simple_2d_game_engine: SDL-based 2D game engine using event system and ECS pattern

github.com

위에서 코드 전문과 깔끔한 글을 읽을 수 있습니다.

simple_2d_game_engine

configure

deps

brew install sdl2 sdl2_image sdl2_ttf sdl2_mixer lua

game things

VSync (vertical sync, 수직 동기화)

아래와 같은 tearing은 게임이 매 프레임마다 렌더링을 하는 사이 모니터의 refresh rate(주사율, 재생률) 과 맞지 않아서 그리는 도중을 보여줘서 보이는 현상임.

이를 위해 게임 렌더러의 프레젠테이션(화면에 그리는 것)을 모니터의 refresh rate와 동기화하는 기술이 vsync이며 결과적으론 tearing을 방지 한다.

추가로, GPU가 모니터의 refresh rate보다 더 많은 프레임을 렌더링하지 않도록 제한함으로써, 불필요한 GPU 부하를 줄일 수도 있다.

문제는 모니터의 refresh rate가 60Hz라면, 게임의 fps는 60fps로 제한되며 (60fps 이상으로 렌더링해도 60fps 이상이라고 인식하지 못함. 애초에 주사율이 초당 60번 refresh되니까.) 만약 60fps를 못 맞춘다면 나누어 떨어지는 30fps로 렌더링됨. 결국 GPU가 힘들면 fps가 낮아짐.

Double-Buffered Renderer

back buffer와 front buffer의 이중 운용.
draw를 back buffer에서 먼저하고 front buffer로 swap하는 방식.
glitch를 방지하고, 렌더링이 완료되지 않은 프레임은 화면에 보여지지 않는 장점이 있음.

Fixed Time Step(Frame Rate Independence) game loop

아래 코드는 while loop를 도는데 구동되는 컴퓨터의 CPU 성능에 의존적이다.
즉, 게임을 구동하는 클라이언트마다 동일한 게임 경험을 줄 수 없다는 것을 의미한다.

void Game::RunGameLoop() {
    Game::Setup();
    while (mIsRunning) {
        Game::ProcessInput();
        Game::Update();
        Game::Render();
    }
}

이 문제에 대한 해결책으로

고정 프레임 레이트 업데이트
시간 기반 업데이트
등... 이 존재한다.

Variable Delta-Time (frame drop compensate with delta time)

unity, love2d 등 웬만한 게임 엔진은 game loop를 메서드 형식으로 노출하고 있다. 그 중에서도 update는 frame마다 호출된다.

따라서, fps가 하락하면 update 호출 횟수도 줄어듦. frame이 바뀌어도 동일한 정도로 움직이게 만들어야 함.

즉, 다른 frame rate에서도 속도 등이 frame rate에 영향을 받지 않게 만들어야 한다.

해결 방법의 핵심 : if frame rate drop, should be compensate for it.

case 1. 60fps -> 30fps
update 호출이 덜 일어나지만 dt가 늘어났으므로 dt를 곱하여 compensate.
case 2. 60fps -> 120fps
update 호출이 더 자주 일어나지만 dt가 줄어들었으므로 dt를 곱하면 compensate됨.
dt를 곱함으로써 frame rate에 영향을 받지 않고, '초' 단위로 속도를 조절할 수 있게 됨.
-- 17pixel per second player.x = player.x + 17 * dt

Determinism

어떤 것이 Deterministic 하다는 것은, 동일한 입력을 제공할 때마다 정확히 동일한 출력이 되돌아오는 것을 의미한다.

대부분 컴퓨터에서는 결정적인 것이 많으므로 비결정적인 것을 살펴보는 것이 더 빠르다. 멀티 쓰레딩, 네트워크, 가변 delta time을 활용한 compensating 등이 비결정적이다. 멀티 쓰레딩을 해봤다면, 동일한 queue에 데이터를 각 쓰레드가 데이터를 던졌다면, 그 순서가 매 실행마다 달라지는 것을 체험해봤을 것이다.

여기서는 게임을 다루고 있으니 variable delta time에 대해서 이야기해보자. variable delta time을 활용했다면 비결정적이다. 왜냐하면, 동일한 입력을 제공했을 때마다 다른 delta time이 반환되기 때문이다.

결정적인 constant delta time을 이용하려면 단순히 1 / fps를 활용하면 된다.

ECS(Entity Component System)

box(entity)에 box collider(component)를 넣어 특성을 부여하는 식의 구현은 unity을 비롯한 게임 엔진에서 흔히 볼 수 있는 시스템.

data-oriented design을 통해 cache-friendly하게 구현하느 것이 목표임. 따라서 OOP와는 다른 구조를 가짐.

OOP와 ECS의 가장 큰 차이점은, OOP에서는 base class와 derived class간의 상속과 위계가 강조되지만 ECS에서는 Component가 데이터를 소유하고, 엔티티는 단순히 컴포넌트의 컨테이너 역할을 한다는 것입니다.

Entity(id)
- 게임 내의 모든 객체나 아이템은 엔티티로 표현됩니다. 엔티티 자체는 단순히 고유 식별자(ID)를 가진 컨테이너에 불과하며, 실제로는 아무런 데이터나 행동을 직접 가지지 않습니다.
Component(data)
- pure data
- pure data라는 관점에서 plain old data(POD)를 표현하기 위한 struct로 구현하는게 잘 어울린다. 그 과정에서 memory padding을 고려하는 것이 좋다. (#pragma pack을 활용하거나 수동으로 구조체 멤버의 순서를 조정하자.)
- 그러나 여러 기능 때문에 class로 구현이 되곤 한다.
- 컴포넌트는 엔티티의 데이터를 나타냅니다. 예를 들어, 위치, 속도, 건강 상태 등과 같은 속성들이 컴포넌트로 표현됩니다. 이들은 엔티티에 첨부되어 엔티티의 상태를 정의합니다.
System(transform data logic)
- entity는 id, component는 data, system은 behavior를 담당한다. 즉, component의 상태 데이터를 변경하는 것이 system의 역할이다.

component의 memory contiguous한 배치와 Pool

ECS에서는 컴포넌트를 사용하여 데이터를 저장합니다. 이 컴포넌트들은 종종 메모리 상에서 연속적으로 배치됩니다. 즉, memory contiguity (메모리 연속성)를 지키도록 배치됩니다.

쉽게 말해서 [comp, comp, comp, comp, ...] 와 같은 꼴입니다.

캐시 친화적 접근: 시스템이 특정 컴포넌트 유형을 작업할 때, 연속된 메모리 레이아웃 덕분에 캐시 효율성이 높아집니다. 예를 들어, 물리 시스템이 모든 위치 컴포넌트를 순차적으로 처리할 때, 연속된 메모리 레이아웃은 캐시 적중률을 높여 성능을 향상시킵니다.
데이터 지향 설계: ECS는 데이터 지향 설계 원칙을 따릅니다. 이는 데이터를 중심으로 시스템을 구성하여, 메모리 접근 패턴을 최적화하는 것을 목표로 합니다. 이러한 접근 방식은 메모리 연속성을 중시합니다.

생각해보면, memory contiguous한 자료구조(vector, array, ...)에 객체를 넣기만 하면 이를 달성할 수 있을 것으로 보인다. 이의 구현체를 관습적으로 Pool이라고 부른다. (DB connection 비용 아끼려고 만드는 pool과는 맥락이 다르니 이해에 주의)

ECS 시스템에서의 Pool이란 컴포넌트를 저장, 관리하기 위한 메모리 저장 영역을 의미한다.

Pool 방식으로 관리함으로써 동일한 유형의 컴포넌트를 연속된 메모리 공간에 저장하여 memory contiguity를 달성함으로써, 메모리 할당 및 해제를 최적화하고, 캐시 효율성이 향상된다.

Pool의 구현은 단순히 memory contiguous한 자료구조(vector, array, ...)에 객체 혹은 식별자를 넣은 것에 불과하다.

해당 엔진에서의 Pool은 (entity의 갯수, component의 갯수)의 이차원 배열 꼴로 아래와 같이 구성된다.

Entity / Component	CompA	CompB	CompC
Entity 0	CompA	CompB
Entity 1	CompA		CompC
Entity 2	CompA	CompB
Entity 3	CompA	CompB	CompC

사실, 이러한 구성은 entity가 가지고 있지 않은 component 부분에 대해서 data cap을 가진, 즉, 메모리를 낭비하는 부분이 있다.

pool의 data gap을 제거하는 방안 (개선안)

즉, component pool을 packed하게 관리해야 한다.
위 방식에 data gap이 발생하는 이유는, 단순히 entityId를 index로 사용하고 있기 때문이다.

가장 간단한 방식으로 해결하려면, entity-index 간 상호 변환 가능한 양방향 맵을 운영하는 것.

DOP (data-oriented programming)

게임 관련 프로그램은 말 그대로 squeeze performance out of hardware를 목표로 한다. 보통 CPU cache hit rate를 높이는 것이 목표이다. 따라서 data locality를 위해 memory contiguity한 처리를 중시한다.

cache fail하면 memory hierarchy 하위인 매체로 접근해야 하는데 (CPU -> RAM -> Disk) 각 매체는 용량과 속도를 trade off한 것이므로 속도가 자연스레 느리다.

array of struct(AOS) vs struct of array(SOA)

// AOS. 흔히 짜던 방식이고 직관적
struct ThreeDimensionalVector {
    double x, y, z;
};
std::array<ThreeDimensionalVector, 1024> arrayOfStruct;

// SOA. DOD에서의 방식
struct structOfArrays {
    std::array<double, 1024> x;
    std::array<double, 1024> y;
    std::array<double, 1024> z;
};

AOS 방식은, x, y, z가 동시에 다 바뀌어야 할 때 유용한 편
SOA 방식은, 어느 한 축의 값만 바뀌는 경우가 많을 때 유용한 편

특정 시스템, 로직은 보통 객체의 한 멤버 변수에만 관심이 있을 때가 많다. 아이템의 수량만 바꾸지, 수량과 이름을 동시에 바꿀만한 경우는 드물다. 그래서 DOD 관점에선 SOA가 더 자주 사용되는 편이라고 한다.
- 메모리 레이아웃으로 따지자면, AOS는 [(x, y, z), (x, y, z)] 꼴일 터이고, SOA는 [x, x, x, ...], [y, y, y, ...], [z, z, z, ...] 와 같은 꼴일 터이다. 특정 로직이 x, y, z가 다 필요하면 AOS 방식이 data locality 측면에서 유리할 것이고, 특정 필드에만 자주 접근하는 경우 SOA 방식이 유리할 것이다.
해당 시스템에서는 직관적인 AOS 방식을 사용하였다. 어.. 사실 뭘 사용하는 지 확실하게 정하는 건 프로파일링을 통해서 성능 차이가 확연한 이점이 있을 때 하는게 좋다고 생각한다. don't premature optimization.

event system

비동기 프로그래밍과 pub-sub

비동기 프로그래밍을 구현하는 패턴으로 다음과 같은 것을 들 수 있겠다.

coroutine, generator
- python 이야기를 하자면, coroutine(generator based), native coroutine(async/await)로 분리할 수 있겠다.
- javascript의 generator는 엄밀히 말하자면 coroutine은 아니다. sub routine간의 양방향 전환이 안되기 때문에 제한된 coroutine이다.
promise(future)
callback
- 그것이 event loop를 타는 것이든(node, python) 단순히 함수 포인터로 호출하는 방식이든(c/cpp)
reactive programming(rx)
observer pattern
- 엄밀히 이야기하면, pub-sub과는 조금 다르다. pubsub은 event channel(이벤트 버스)를 통해 이벤트를 전달하는 것이고, observer pattern은 subject가 observer에게 직접 이벤트를 전달하는 것이다.

거칠게 요약하자면 비동기 프로그래밍은 pub-sub 패턴의 변형이다.
본 엔진에서 구현되는 이벤트 시스템도 pub-sub 패턴의 변형이다.

어떠한 topic에 대해 subscribe하고 어떤 동작을 지정하면,
eventBus가 각 이벤트의 리스너와 콜백의 목록을 관리하고, 이벤트를 전송하는 역할을 한다.
그리고 이벤트 emit(publish) 되는 시점에 동작이 실행된다.

collision check

이 엔진에선 box collider로 감싼 entity의 충돌을 AABB collision check로 확인함.

circle collision detection

단순하게, 원의 중심점 사이의 거리가 반지름의 합보다 작으면 충돌이 발생한 것으로 간주한다.

AABB collision detection

AABB (Axis-Aligned Bounding Box) collision check는, 단순히 entity를 감싼 collider 가 겹치는 가를 확인하는 로직이다.

박스 A, 박스 B가 존재한다고 가정할 때 두 영역이 충돌(영역 겹침) 확인 조건.

A의 최대 X 좌표(A.x + A.width)가 B의 최소 X 좌표(B.x)보다 커야 함
A의 최소 X 좌표(A.x)가 B의 최대 X 좌표(B.x + B.width)보다 작아야 함
A의 최대 Y 좌표(A.y + A.height)가 B의 최소 Y 좌표(B.height)보다 커야 함
A의 최소 Y 좌표(A.y)가 B의 최대 Y 좌표(B.y + B.height)보다 작아야 함

language interoperability(언어 간 상호 운용성)

다른 언어간의 바인딩 작업은, 개발 전략적으로 중요하다.

core engine은 성능을 위해 저수준 언어로 개발하고, 상위 추상화 계층에선 script 언어를 사용하는 패턴은, 게임 엔진 뿐만 아니라 tensorflow, pytorch와 같은 cpu bound한 작업을 요구하는 소프트웨어에서 squeeze performance out of hardware를 위해 많이 사용되는 패턴이다.

이를 구현하는 방법을 생각해보자면 아래 정도가 있겠다.

FFI(Foreign Function Interface)가 지원되면 사용하거나 (deno 같은 경우에는 내장으로 FFI를 지원한다.)
저수준 언어에서 스크립트 언어를 embedding하거나,
고수준 언어에서 컴파일된 binary를 통으로 불러와서 아예 실행하던가,
서로 다른 책임을 가진 두 언어로 만들어진 프로그램을 실행하여 프로세스 간에 통신하거나(이 방법은 언어 간 상호 운용이라는 측면에서는 좀 벗어난 측면이 있지만)

해당 엔진에서는 sol을 통해 간단하게 cpp과 lua 간의 바인딩을 구현하였다.

SLD2

paths

# sd2 check
sdl2-config --version # 2.28.5

sdl2-config --libs
# 링커 플래그 제공
# 링커가 SDL2 라이브러리를 찾고 링크하는 데 필요한 설정을 제공합니다

sdl2-config --cflags
# 컴파일러 플래그 제공
# SDL2 헤더 파일의 경로를 출력.
# 컴파일러가 SDL2의 헤더 파일을 찾을 수 있도록 해줍니다.

sdl2-config --libs --cflags # 동시에 출력

# 현재 맥 환경에선 --cflags가 -I/opt/homebrew/include/SDL2 -D_THREAD_SAFE 를 출력함.
# 문제는 이렇나 방식이면 #include <SDL.h> 방식으로 include해야 함.
clang++ -Wall -std=c++17 Main.cpp $(sdl2-config --libs --cflags) -o Main

# 코딩 컨벤션에 맞게 <SDL2/SDL.h> 로 사용하기 위해 -I 옵션을 수정하여 아래처럼 적용함.
clang++ -Wall -std=c++17 Main.cpp -L/opt/homebrew/lib -lSDL2 -I/opt/homebrew/include -D_THREAD_SAFE -o Main

full screen, fake full screen

full screen은 다른 화면 전환이 번거로움. (전체 화면)
Fake Fullscreen은 사실상 크기를 조정한 창 모드. (전체 창모드)

SDL_WINDOW_FULLSCREEN
- 전체 화면. SDL이 해상도를 변경하여 전체 화면으로 만듬.
- 화면 전환 시 느림. (게임 하다가 ctrl + tab으로 전환하려고 하면 해상도 깨졌다가 다시 복구되는 그것.)
SDL_WINDOW_FULLSCREEN_DESKTOP
- fake full screen으로, 해상도 변경 없이 전체 화면처럼 보이게 함.
- 전체 화면을 채우는 보더리스 창을 생성하는 것과 유사.
SDL_WINDOW_BORDERLESS
- 전체 화면과 크게 관련 없으나 전체 화면을 꽉 채우는 borderless 창을 생성하는 것과 유사.

rendererFlags and hardware acceleration

SDL_CreateRenderer에서 GPU 사용이 가능

SDL_RendererFlags 참고.

SDL_RENDERER_SOFTWARE : 하드웨어 가속 사용 안하고 CPU 사용
SDL_RENDERER_ACCELERATED : dedicated graphics card (GPU) 사용
SDL_RENDERER_PRESENTVSYNC : VSync 사용. tearing 방지
SDL_RENDERER_TARGETTEXTURE

SDL_CreateRenderer(
    window,
    -1,
    SDL_RENDERER_ACCELERATED
);

surface vs texture

SDL_Surface는 이미지 처리나 간단한 소프트웨어 렌더링에 적합하고, SDL_Texture는 GPU를 사용한 빠른 화면 렌더링에 적합합니다.

일반적으로 이미지 파일을 로드하고 조작할 때는 SDL_Surface를 사용하고, 화면에 이미지를 렌더링할 때는 SDL_Texture로 변환하여 사용합니다.

SDL_Surface는 시스템 메모리(RAM)에 저장되고, SDL_Texture는 GPU의 비디오 메모리(VRAM)에 저장됩니다.

etc

UI paradigm (retain vs immediate)

retain mode(RMGUI)
web에서 vanilla js로 DOM을 구성하는 것과 비슷하다.
UI 요소를 객체로 보고, UI가 바인딩한 데이터의 변화에 따른 변화를 처리하도록 해당 객체를 구성해야 한다. 따라서 해당 UI가 state의 변화 로직과 변화에 따른 렌더링 로직을 모두 가지고 있어야 한다.
- UI의 상태가 지속적으로 저장 및 관리되어야 하는 경우 사용
- UI와 데이터를 바인딩(sync)하여 사용하는 대부분의 SPA 프레임워크의 방식
immediate mode(IMGUI)
게임 루프에 UI 렌더링을 태워서 UI를 새롭게 그려낸다. 그래서 UI가 데이터를 직접적으로 소유하지 않고 바인딩하는 것도 없다.

About the IMGUI paradigm

OTF(OpenType Font), TTF(TrueType Font)

둘 다 많이 쓰이는 폰트 포맷이다.
OTF는 TTF보다 더 많은 기능을 제공하는 대신 더 큰 용량을 차지하곤 하며,
오래된 브라우저에서는 지원하지 않는 경우도 있다.

lldb 두 번 쓰세요

b [function-name] 나 b [file]:[line]로 의심되는 지점을 건다.
r로 실행한다.
다음과 같은 도구들을 이용해본다
- 뭔가 터지면 bt로 스택 트레이스를 확인한다.
- 문제가 되는 메모리 공간을 memory read [주소]로 확인한다.
- expr [변수명] = [새로운 값]으로 새로운 값으로 변경해본다
- expr [변수명] 혹은 p [변수명] 으로 변수를 확인해본다
- frame variable [변수명], fr v [변수명]으로 현 프레임에서의 변수의 값을 확인한다.

known issues

다중 모니터 문제
- 전체 화면 문제
  monitor 0, 1 두 개의 모니터가 존재할 때,
  monitor 0에서 전체 화면 게임을 실행하면 monitor 1은 어떻게 해야 하는가? (모니터에 따라 동작이 다른 것을 확인)
- 화면 분할 문제
- 내장 모니터가 3456 x 2234임에도 화면 분할 기능을 사용하면 1728 x 2234로 나눠지게 된다.
  전체 화면 게임을 실행할 경우 어떻게 대처할 것인가?

개인적인 coding convention이나 기타 개발 관습에 대해

여기서는 struct와 class를 혼용하였다. 그러나 struct는 POD만을 담도록 하는 것이 좋다고 생각한다.
c lib는 smart pointer로 wrapping하지 않는다.
여기서는 대입을 통해 멤버 변수를 초기화한 부분이 있으나 가급적 initializer list를 사용하는 것이 좋다고 생각한다.
IDE로 vscode를 사용 중인데, c/c++ extension가 제공해주는 intellisense가 아주 느리다. clangd 사용을 권장하며, 사용하는 빌드 시스템 툴에 따라 compile_commands.json을 생성하여 사용하자.
enum 보다 enum class가 strongly typed기도 하고, enum의 class를 명시하는 효과가 있어서 더 자주 사용하는 편이다. 특히, 타 언어에서 그런 표기법을 사용하는 경우가 많아서 익숙하다.
DO NOT USE EXCEPTION. just let engine crash.
타 언어일 때는 inlay hints가 지저분해보였는데 c/cpp에서는 이게 없으면 코드 읽기가 더 힘들어지는 듯. 활성화 추천.

resources

use vscode for Unity external editor + omnisharp intellisense setting in MAC!

DarrenKwonDev — Sat, 30 Sep 2023 10:11:42 +0900

you should know, C# does not well-supported arm64. so using C# in mac is quite annoying.

I'll omit to install process like dotnet, unity, and so on.

downgrade C# extension to 1.24.0.

(it's triggering my temper...)

do not use the modern net. not support Unity

instead, use mono framework

after that, you can get 'omnisharp server running' in bottom of vscode.

It takes about 3~5 sec to fully working. so be patient.

there's omnisharp logo in bottom right

네이버 부스트캠프 AI Tech 합격 후기

DarrenKwonDev — Thu, 9 Feb 2023 21:14:19 +0900

퇴사 후 recsys를 공부하고 싶다는 생각이 들었습니다.

통계 스터디를 진행하면서 수학과 통합된 기능 개발을 하고 싶었고(비록 첫 회사에서 개발한 추천 시스템은 무산되었지만) 무엇보다 일반 backend의 업무보다 보다 전문성 있을 것같다는 생각이 들었거든요. 더 나아가서 뭔가 수학적인 일을 하고 싶다는 모호한 욕망도 있었습니다.

지금까지 해왔던 것처럼 독학을 할 수도 있었겠지만 독학이 조금 지치기도하고 교육기관을 알아보았습니다.

교육 기관을 조사해보니 국내에서 AI나 ML을 말하면서 NLP나 CV를 (어영부영) 가르쳐주는 곳은 많았지만 AI, tech의 hype를 타고 급조되어 만들어진 것에 대부분으로 보였습니다.

사실 위와 같은 분야에서 실제로 어떠한 성과를 이뤄내려면 부트캠프가 아닌 대학원에 가야 한다고 생각합니다.

저는 연구가 목적이 아닌 엔지니어링을 기반으로 한 비즈니스에 관심이 있었기에 recsys에 좀 더 관심이 갔습니다. 그러나 recsys를 교육 과정에 포함한 곳은 드물었습니다. buzz word를 이미 좀 지나쳐온 것이라서 그런 것으로 추측됩니다.

여튼, Naver AI boostcamp가 가장 합리적인 선택이라고 생각하고 전형을 진행하였습니다.

0. 진행과정 overall

pre-course는 선형대수, 머신러닝과 딥러닝의 기초에 대한 강의를 수강하고 인증하는 것입니다.

이미 관련 지식이 있으신 분은 쉽게 이해하실 수 있습니다. 다만, 강의를 너무 빠른 배속으로 듣게 된다면 수업 완료가 되지 않기에 이를 유의하시는 것이 좋습니다.

1. 지원서 작성

차후 달라질 수 있으나 아래와 같은 질문에 답하면 되었습니다.

이런 질문이 으레 그러하듯 가급적 limit까지 분량을 '내용있게' 채우는 것을 기본 전략으로 하였습니다.

이타적인 모습과 학습에 대한 열의를 앞에 배치하고, 이에 해당하는 증거나 스펙 등을 후에 첨부하였습니다.

- 부스트캠프 AI Tech 교육은 어떤 이유로 지원하셨나요? 여러 교육과정 중에서 부스트캠프를 선택한 이유와 AI 엔지니어가 되기로 결심한 이유를 알려주세요 (500자 내외)

- 지금까지 소프트웨어 개발 관련 경험 또는 인공지능을 배우기 위해 시도했거나 참여한 경험을 모두 적어주세요. 결과물보다 그 과정에서 무엇을 고민했고 어떤 점을 배웠는지를 자세히 작성해주세요.(500자 내외)

- 부스트캠프는 5개월 정도를 온라인 환경에서 몰입하여 풀타임으로 학습해야 합니다. 이러한 몰입 과정이 끝나면 개인적으로 많은 성장이 있을 텐데요, 교육 수료 후 5년 뒤 본인은 어떤 개발자로 성장하여 어떤 꿈을 펼치고 있을지 최대한 자세히 작성해주세요. (500자 내외)

- 부스트캠프 교육은 자기주도적인 학습과 동료와 원활한 소통을 중시합니다. 원활한 교육진행을 위해 기존에 자기 스스로 학습한 기억 또는 성공적인 커뮤니티 활동 경험을 소개주세요. (서술은 300자 내외)

자소서와 별개로, 포트폴리오나 github를 첨부할 수 있는데 이도 모두 제출하였습니다.

2. 1차 시험: 머신러닝 기초 퀴즈 및 코테

수학 및 머신러닝의 기초에 대해서는, pre-course를 잘 수강한 후에 자가 진단을 한 번 다 풀어보고 유형을 정리하는 것을 추천드립니다.

코딩 테스트는 자세한 내용을 말할 수 없으나 백준 기준 브론즈~실버 수준이며 프로그래머스 0~1 단계의 문제들로 이루어져있었습니다.

다만 코딩 테스트의 난위도는 널뛰기할 수 있습니다. 전 기수는 2차 코딩 테스트보다 1차 코딩테스트가 너무나 어려웠기에 2솔이 컷이었다는 말이 있습니다.

3. 2차 시험: 코테

1차보다 좀 더 심화적인 문제가 나옵니다. 백준 기준 실버 ~ 골드 수준이며 프로그래머스 2~3 단계로 느껴졌습니다.

8문제 중 5문제를 풀고 합격을 받았습니다. bfs, dfs, greedy, 구현과 같은 기본적인 유형에 집중하는 것으로 충분했었습니다.

latex 기반의 이력서

DarrenKwonDev — Fri, 21 Oct 2022 02:32:05 +0900

https://github.com/James-Yu/LaTeX-Workshop/wiki/Install

GitHub - James-Yu/LaTeX-Workshop: Boost LaTeX typesetting efficiency with preview, compile, autocomplete, colorize, and more.

Boost LaTeX typesetting efficiency with preview, compile, autocomplete, colorize, and more. - GitHub - James-Yu/LaTeX-Workshop: Boost LaTeX typesetting efficiency with preview, compile, autocomplet...

github.com

설치된 texlive는 /usr/local/texlive 경로 하위에 bin 폴더 내부에 있으므로 PATH에 추가할 것.

overleaf의 잘 구성된 cv 참고할 것

https://www.overleaf.com/gallery/tagged/cv

빌드하여 제출한다.

VSCode 설치했으면 여기 오세요 : 내가 사용하는 VSCode

DarrenKwonDev — Thu, 3 Feb 2022 09:57:43 +0900

기본 Shell을 bash 혹은 zsh로 교체하기

F1을 누르고 Select Default Shell을 통해 설정해주자

윈도우 환경이라면 git bash를 선택해주자 bash를 사용할 수 있게 된다!

'code' command PATH에 추가하기

자동 포매팅 설정

세팅에서 그냥 format on save를 켜면 되는 일이지만,

json에서는 다음과 같이 언어별 설정이 가능하다.

그리고, eslint를 사용한다면 저장 시 포매팅 기능은 꺼두는 것이 좋다.

"[javascript]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascriptreact]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescriptreact]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode"
},
{
 "[dart]": {
      "editor.defaultFormatter": "Dart-Code.dart-code",
      "editor.formatOnSave": true,
      "editor.rulers": [120]
    }
}

inlay hint

"javascript.inlayHints.parameterNames.enabled": "all"
"typescript.inlayHints.parameterNames.enabled": "all"

jsx에서 html 태그 완성이 잘 안될 때.

"emmet.includeLanguages": {
    "javascript": "javascriptreact" // jsx에서 html 태그 자동완성이 안 됐었는데, 이 부분 추가해서 해결했다.
  },

deno 프로젝트에 세팅하기. globally enabled 시키면 일반 노드 프로젝트에서 deno 랭귀지 서버를 쓰게 되어 이상한 곳에서 경고를 보냄.

{ "deno.enable": true }

VSCode 설정 싱크하기

extension이 많아졌을 때 + 다른 컴퓨터에서 작업을 해야만 하거나 새 컴퓨터를 샀을 때. 설치에 시간을 쏟고 싶지 않다면 VSCode를 sync하는 방법을 고려해보자

핵심은

발급받은 토큰을 사용하여 github에 vscode 설정 upload
- shift + alt + u 단축키를 누르고 입력란에 발급받은 토큰을 입력합니다.
발급받은 토큰을 사용하여 기기에서 download
- shift + alt + d 단축키를 눌러 동기화가 필요한 기기에서 다운받습니다.

https://ithub.tistory.com/211

VSCODE 유용한 플러그인 settings sync 사용하기

안녕하세요. 오늘은 vscode를 집, 회사 등 여러 디바이스에서 동일한 환경을 사용할 수 있게 해주는 플러그인 Settings Sync 사용법에 대해서 를 알아보겠습니다. 직접 설정한 설정정보와 설치한 플러그인까지 여..

ithub.tistory.com

alt + shift + i + (home/end) 로 다중 선택, 이동, 수정

기본적인 VSCode 단축키는 직접 찾아보면 되지만 여기서 소개하는 이 단축키는 워낙 유용해서 올려본다.

alt + shift + i + (home/end)이다.

단순 반복을 해야 하는데 매 줄마다 길이가 다르다면 곤란하다.

alt + clcik으로 매번 클릭하기도 힘들다. 특히 다음과 같은 코드가 있다고 가정한다면... ( )

class Block {
  public index: number;
  public hash: string;
  public previousHash: string;
  public data: string;
  public timeStamp: number;

  constructor(
    index: number,
    hash: string,
    previousHash: string,
    data: string,
    timeStamp: number
  ) {
    this.index = index;
    this.hash = hash;
    this.previousHash = previousHash;
    this.data = data;
    this.timeStamp = timeStamp;
  }
}

export {};

드래그한 후 alt + shift + i를 누르면 다음과 같이 된다.

이 상태에서 home/end를 통해 해당 코드의 맨 앞/맨 뒤로 이동할 수 있다.

빈 폴더를 나열식으로 보는 방법

빈 폴더를 생성하면 VSCode에서는 다음과 같이 보여주는데 이게 여긴 귀찮고 불편한 게 아니다. preference에서 해당 기능을 꺼주자. 해당 기능 이름은 compactfolers이다.

vscode prettier formatter가 작동을 안한다면

stackoverflow.com/questions/52586965/why-prettier-does-not-format-code-in-vscode

react-native나 뭔가 새로운 걸 할 때마다 작동을 안하는 경우가 있다.

default formatter를 esbenp.prettier.vscode로 설정하고, 저장 시 포매터를 켜야 한다.

x가 x로 인식되지 않고 y로 인식된다면?(ex-내 html이 django-html-template으로 인식된다면?)

위 사항은 대표적인 사항이고, 이 뿐만 아니라, 특정 파일이 본 파일이 아닌 extension에 의해 다른 것으로 인식될 때가 있다.

괜히 익스텐션 깔았다 지웠다 하지 말고 file: Associations를 이용하여 직접 잡아주면 된다.

저는 프로젝트에 eslint + prettier를 쓸거라서 format on save를 끄고 싶은데요

eslint를 이용하려면

프로젝트 소스코드 내에 eslint 구성은 생략하고, vscode에서 이를 활용하기 위해 세팅 작업을 해줘,

command + shift + p => open setting (json) => 아래 내용 붙여넣기.

만약 저장시 포매팅 작업을 체크해놨다면 해제해야 한다.

일단은 js, ts만 eslinting을 하기로 하자. 사실 이 두 언어 외에서 eslint를 쓸 일이...있나? 싶다.

"editor.codeActionsOnSave": {
      "source.fixAll.eslint": true
  },
  "eslint.alwaysShowStatus": true,
  "eslint.workingDirectories": [
      {"mode": "auto"}
  ],
  "eslint.validate": [
      "javascript",
      "typescript"
  ],

저장시 eslint의 규칙에 맞게 자동으로 세팅해준다!

당연한 말이지만, .eslintrc를 설정한 프로젝트에서만 저장시 eslint에 의해 포매팅이 된다.

협업할 때 => 오토 포매팅 꺼두고 eslint+prettier가 돌아가게 해두자

혼자할 때 => 협업 세팅을 그대로 써도 되고, eslint가 거슬리면 저장시 포매팅을 켜서 사용하면 된다.

C/C++ 등을 VScode에서 사용하고 싶다면

javascript, go, dart 등은 vscode에서 뚝딱이지만

c, cpp은 visual studio를 주로 사용한다.

그럼에도 용량이라던가, 컴퓨터 사양에 의해 vs를 사용할 수 없다면 vscode를 사용해보자.

솔직히 연습할 때 vscode가 더 나은 것 같기도 하다...

darrengwon.tistory.com/1091

C/C++ in VSCode / code runner! / formatting

왜 VS안 쓰심? 무겁다. 게다가 visual studio 컴파일러보다 gcc 컴파일러를 사용하고 싶었기 때문이다. "visual studio에서는 되는데 왜 이 환경에서는 안되지?"와 같은 상황이 싫었다. 그래서 Clion을 쓸 것

darrengwon.tistory.com

rainbow extension deprecated -> using native vscode

flavor 분리에 따른 iOS info.plist 자동 변경을 위한 bash script

DarrenKwonDev — Thu, 27 Jan 2022 17:42:25 +0900

flavor 분리는 다른 팀원 분이 해주셨는데 문제가 iOS에서 빌드시 다음과 같은 꼴을 유지해야 했다.

1. iOS 경로에 GoogleService-info.plist가 위치

2. 그 다음 프로젝트 내의 Info.plist의 CFBundleURLSchemes 하단 부분에 flavor에 해당하는 REVERSED_CLIENT_ID를 주입

해야 하는 지점이 있었다. XCode를 통해서 Add Files to "Runner"로 직접 넣어주면 되었지만 개발 중에 이들을 신경쓰기가 너무 불편하더라. 자동화하기 위해 Build Phases에서 빌드시 호출되는 로직 중 다음과 같이 bash shell을 끼워주었다.

짜면서 얻은 교훈은

1. bash script가 생각보다 표기법이 불친절하다. 비교문의 [ ] 내부에 공백이 반드시 존재해야 한다던지 하는 룰이 익숙하지 않았다. bash를 계속 짜다보면 익숙해지긴 할 것이다. 시간이 많이 남았더라면 google이 만든 zx를 사용해보아도 좋을 듯하지만 여기서는 bash를 사용했다. https://github.com/google/zx

2. 크로스 플랫폼이라고는 하지만 native 언어와 플랫폼에 대한 지식은 반드시 필요하다. '덜' 필요할 뿐이지. 그리고 충분히 복잡한 어플리케이션을 제작해야 한다면 native 단을 건드리는 일이 훨씬 잦아질 것으로 예상한다. React 개발자 몇 명 있다고 React-native 앱 개발하라고 던져 놓으면 하긴 하겠지만 시행 착오에 드는 리소스 + 네이티브 학습 비용까지 고려한 일정을 잡아줘야 한다. 정말루... 아니면 native 개발자를 모셔오는 게 맞다. 그리고 일반 웹 개발자라가 모바일 앱에 발이라도 들여 놓으려면 최소한 kotlin이랑 android는 배워놔야 한다는 생각이 많이 든다.

3. iOS 개발에 있어서 XCode에 익숙해지는 것은 필수 불가결한 일 같다. 우리가 아는 일반적인 파일 시스템과는 다른. reference로 파일을 복사하는 것과 아닌 것을 구분한다던지, 특정한 방식으로 파일을 추가하면 부가적인 파일이 수정, 추가된다던지 하는 일이 잦다. 예를 들자면, 최초로 GoogleSerivce.plist를 일반적으로 추가하는 것과 XCode의 Add Files to "Runner"를 통해 추가하는 것은 Info.plist를 생성해주느냐 안해주느냐의 차이가 있다. iOS 개발을 전혀 모르면 나처럼 삽질을 장시간 할 수 밖에 없다...

4. 웬만히 다급하거나 답이 없는게 아니라면 plist를 하드 코딩으로 수정하지 말자. plistBuddy나 plutil을 통해서 코드로 조작하는게 좋다.

대충 다음과 같이 생겼다. 실제로는 이것저것 더 있긴한데, 앞서 설명한 프로세스와는 관련이 없어서 지웠다.

script를 읽고 프로젝트에 적합하게 알아서 가공해서 쓰면 되겠다...

environment=""

# 환경을 얻기 위해서 정규식으로 발라내기
# CONFIGURATION="Debug-prod" 꼴이면 "prod"를 반환
if [[ $CONFIGURATION =~ -([^-]*)$ ]]; then
environment=${BASH_REMATCH[1]}
fi

echo $environment

# GoogleService-Info.plist의 경로
GOOGLESERVICE_INFO_PLIST=GoogleService-Info.plist
GOOGLESERVICE_INFO_FILE=${PROJECT_DIR}/firebase/${environment}/${GOOGLESERVICE_INFO_PLIST}

# GoogleService-Info.plist가 경로에 존재하는지 체크
echo "Looking for ${GOOGLESERVICE_INFO_PLIST} in ${GOOGLESERVICE_INFO_FILE}"
if [ ! -f $GOOGLESERVICE_INFO_FILE ]
then
echo "No GoogleService-Info.plist found. Please ensure it's in the proper directory."
exit 1
fi

# GoogleService-Info.plist를 복사할 경로
PLIST_DESTINATION=${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app

# release 빌드와 debug 빌드를 위해 GoogleService-Info.plist를 필요한 곳에 복사
cp "${GOOGLESERVICE_INFO_FILE}" "${PLIST_DESTINATION}"
cp "${GOOGLESERVICE_INFO_FILE}" "${PROJECT_DIR}"

# Info-plist의 CFBundleURLSchemes를 교체하기 위한 로직
INFO_PLIST_FILE=${PROJECT_DIR}/Runner/Info.plist

# GoogleService-info.plist의 REVERSED_CLIENT_ID를 불러옵니다.
REVERSE_CLIENT_ID=""

# 만약 googleService가 바뀔 경우 여기에 있는 값들도 변경되어야 합니다.
if [ "$environment" = "dev" ]; then
    REVERSE_CLIENT_ID="dev일 때의 REVERSE_CLIENT_ID"
elif [ "$environment" = "staging" ]; then
    REVERSE_CLIENT_ID="staging일 때의 REVERSE_CLIENT_ID"
elif [ "$environment" = "prod" ]; then
    REVERSE_CLIENT_ID="prod일 때의 REVERSE_CLIENT_ID"
else
    echo "environment is not correct, REVERSE_CLIENT_ID will be empty string"
fi

# echo "removing current url string"
plutil -remove CFBundleURLTypes.0.CFBundleURLSchemes.0 $INFO_PLIST_FILE

# echo "updating with new url string"
plutil -replace CFBundleURLTypes.0.CFBundleURLSchemes.0 -string $REVERSE_CLIENT_ID $INFO_PLIST_FILE

null safety

DarrenKwonDev — Mon, 3 Jan 2022 21:57:22 +0900

런타임 시점에 null이 들어오게 되어 발생하는 에러를 방지하고자 함.

이전과 다르게 모든 자료형은 nullable(?)이 붙지 않는 이상 non-nullable로 취급됨.

dart의 타입 시스템이 바뀌었음

https://dart.dev/null-safety/understanding-null-safety

Understanding null safety

A deep dive into Dart language and library changes related to null safety.

dart.dev

좌측이 null safety가 적용되기 전의 타입 시스템이라면 null safety가 적용되고난 후에는 우측처럼 되었다.

Null이 별도의 타입 처리된 것이다.

https://dart.dev/null-safety/understanding-null-safety

더 나아가 String? 꼴과 같이 nullable 타입을 지정하게 되었다.

https://dart.dev/null-safety/understanding-null-safety

또한 최하단에 Never라는 타입이 오게 되었는데 사실상 추상적인 개념이라고 보아야할 듯 싶다.

null이 별도 타입 처리되면서 강조되는 문법들

코드랩 한 번 쫙 돌려주면 게임 끝

https://dart.dev/codelabs/null-safety

Null safety codelab

Learn about and practice writing null-safe code in DartPad!

dart.dev

exception으로 처리

일반적으로 그냥 null 잡아서 throw Exception해도 된다.

int getLength(String? str) {
  if (str == null) {
    throw Exception("str is null");
  }
  
  return str.length;
}

Nullish coalescing operator (??)

??를 통해 null일 경우 할당할 값을 지정할 수 있음

int? nullableVar = null;
int a = nullableVar ?? 1;
print(a);

Optional chaining (?.)

int? a = null;
print(a?.toString());

null assertion (!)

!를 통해 non-null assertion을 할 수 있음. 당연히 런타임에 확실하게 null이 절대 들어올 일 없다고 확신해야만 사용해야 함.

  int? couldBeNullButIsnt = 1;
  List<int?> listThatCouldHoldNulls = [2, null, 4];

  int a = couldBeNullButIsnt;
  int b = listThatCouldHoldNulls.first!; // first item in the list
  int c = couldReturnNullButDoesnt().abs(); // absolute value

Generic과 관련된 nullable 예시

List<int> a = [3, 4, 1, 5];
List<int>? b = null; // List 자체가 null이 될 수 있다
List<int?> c = [1, 3, null, 4]; // 원소에 null이 들어올 수 있다
List<int?>? d = null; // List 자체가 null이 될 수도 있고, List가 있더라도 원소 중 null이 존재할 수 있다.

late 키워드

써보니 이 녀석은 "곧 할당 될거니까 nullable 처리 안해줘도 그냥 좀 넘어가라"라는 의미다.

class Meal {
  // late 처리가 없다면non-nullable 필드는 반드시 초기화 되어야 한다고 경고뜸
  late String _description; 

  set description(String desc) {
    _description = 'Meal description: $desc';
  }

  String get description => _description;
}

순환 참조에 있어서 late 활용

그러니까 Team은 Coach가 있어야하고 Coach는 Team이 있는, 순환 참조의 형태인데 이럴 경우 late 처리를 해줘야한다.

안해주면 초기화하라고 경고 뜬다

class Team {
  late final Coach coach;
}

class Coach {
  late final Team team;
}

void main() {
  final myTeam = Team();
  final myCoach = Coach();
  myTeam.coach = myCoach;
  myCoach.team = myTeam;

  print('All done!');
}

late를 활용한 lazy 초기화

(https://dart.dev/null-safety/understanding-null-safety#lazy-initialization)

int _computeValue() {
  print('In _computeValue...');
  return 3;
}

class CachedValueProvider {
  // 여기에 late 키워드를 붙이면, 요구하기 전까지 _computeValue 실행을 미룬다.
  final _cache = _computeValue(); 
  int get value => _cache;
}

void main() {
  print('Calling constructor...');
  var provider = CachedValueProvider();
  print('Getting value...');
  print('The value is ${provider.value}!');
}

감이 오겠지만 late를 사용하면 _computeValue는 print('The value is ${provider.value}!');에 의해 호출되어 필요해질 때 실행된다.

추가적으로

typescript 처럼 flow analysis 분석해줘서 type narrowing이 된다. 너무 편함!

ref)

https://www.youtube.com/watch?v=tP9TcrUZoIs

https://dart.dev/null-safety