교체가 많은 시스템에서 특정 기능(예: tty로 전환하는 Alt+Ctrl+F1)을 사용할 수 있는지 확인하는 방법은 무엇입니까?

믿다. :(. 여기서는 단일 사용자 시스템을 고려하고 있다고 가정하므로 SaK(전체 로그인 종료)는 실제로 도움이 되지 않습니다.

하드 드라이브 활동 지표를 이해하십시오. 일을 빨리 끝내는 방법을 알아라. 때로는 그것이 당신을 구할 수도 있고 때로는 그렇지 않을 수도 있습니다.

Exchange는 합리적으로 잘 작동했습니다. 이제 RAM은 더 빠르고 더 커지고 하드 드라이브도 더 커지지만 상대적인 속도(특히 랜덤 액세스)는 형편없습니다. Windows에서는 얼마나 무서운지 상한선을 설정하기 위해 많은 노력을 기울였습니다. Linux 아니요. 촬영은 사용자에게 맡기십시오.

RAM이 충분하고 최대 절전 모드가 필요하지 않은 경우 스왑을 비활성화하는 것이 좋습니다. 최대 절전 모드가 필요한 경우... 메모리와 동일한 크기의 스왑 공간이 필요합니다. :(. 확실히 스크립트로 작성하는 것이 가능합니다. 적어도 pm-utils에는 설치를 위한 멋진 아키텍처가 있지만 공식 지원은 부족할 수 있습니다. (일시 중단하기 전에 사용자 정의 스왑 장치를 추가하고 복구 후에 제거하십시오. 또한 Recovery=boot 옵션을 추가해야 할 수도 있습니다).

즉, 커널 모드 스위치가 있으면 ctrl+alt+f1이 더 잘 작동합니다. (그렇지 않으면 X 서버가 일부 작업을 수행해야 하며 사용자 공간 프로세스입니다. 일부 부분을 교체할 수 있는 Windows와 달리 전체 커널은 항상 RAM에 있습니다.) nvidia와 같은 바이너리 드라이버는 여기에서 당신의 친구가 아닙니다.

우선 포스팅이 길어져서 죄송합니다

Windows 작업 관리자와 비교하면 FOSS의 진부한 표현처럼 들릴 수 있습니다.

GNU/Linux의 특정 기능이 왜 그런 방식으로 설계되었는지 이해하기 쉽게 만드는 한 가지는 Windows가 대부분의 Linux 배포판(Ubuntu는 제외) 설계의 기준점이 아니라는 점을 상기시키는 것입니다. 예를 들어, Red Hat은 수십억 달러 규모의 회사이지만 기존(독점) Unix 공급업체에 대한 저렴하고 사용하기 쉬운 대안으로 기업 사용자에게 자신을 홍보하고 HP-UX Solaris, AIX, 등 이 목표를 달성하기 위한 경쟁. 대부분의 Unix 배포는 고급 데이터 센터에 있으므로 Unix를 유지 관리하는 사람은 누구나 일정 수준의 기술 지식을 보유하고 시스템 관성, 잘 정의된 변환 프로세스, 곧. . , 높은 수준의 세분성 제어가 가능합니다.

이러한 (합리적인) 사고 방식은 Window 디자인과 정반대입니다. 모든 것을 정상화하면 단일 기본 솔루션이 제공되어 자신만의 브랜드로 만들 수 있으며 고급 사용자라면 구성에 몇 가지 기본 변경 사항을 적용할 수 있습니다. , 가서 "낮은 수준" 항목을 변경하십시오(Unix 관리자의 "낮은 수준" 개념과 Windows 관리자의 "낮은 수준" 개념은 이러한 설계 차이로 인해 매우 다릅니다). Windows 관리자의 경우 AD Kerberos 서버의 HMAC 확인/변경은 l33t로 간주됩니다(적어도 일반 AD 관리자는 AD가 MD4 해시를 사용한다는 사실을 모르기를 바랍니다). 반면 Unix에서는 HMAC, 비밀번호 등이 서버의 일부를 설정하는 것은 회사의 솔루션을 설계할 때 고려해야 할 사항 중 일부일 뿐입니다.

배포에 소요되는 시간을 줄이기 위해 일을 계속 진행하는 것이 반드시 나쁘다는 것은 아닙니다. 때로는 솔루션이 필요할 수도 있고 관리 제어를 통해 제공되는 가치가 이 정도의 명확성을 가질 만큼 가치가 없는 경우도 있습니다. 이것이 Red Hat이 여전히 FreeIPA(포인트 앤 클릭 ID 관리) 및 ktune(시스템의 용도에 가장 적합한 "프로파일"을 선택하여 기본 성능 조정)과 같은 기능을 개발하는 이유입니다. 그러나 Unix 관점에서 볼 때 대부분의 MS 제품은 특히 한 가지 질문에 직면하는 모든 문제를 해결하는 데 사용되는 경우 나쁜 관리 업무 윤리를 조장하는 소프트웨어로 간주됩니다(어떤 작업 흐름이 가장 효과적인지에 대해 오해를 불러일으킴). 이는 귀하의 업무를 더 쉽게 해주지만 고용주의 효율성을 떨어뜨립니다.

이에 대해 자세히 설명하고(너무 늦었지요?) 기술적으로는 의미가 없지만 어쨌든 구현되는 Windows의 일부 기능에 대해 이야기를 시작할 수 있지만 아이디어는 이해하실 것입니다.

Window의 디자인에 대해 Unix/Linux 관리자들은 가슴을 치며 가식적인 태도를 취하는 경우가 많습니다(그 중 일부는 단지 "증오하는 사람은 싫어할 것입니다" 또는 화자의 자만심입니다). 그러나 논쟁을 충분히 오랫동안 파고들면 다음과 같은 결론을 얻을 수 있습니다. 문제는 운영 체제가 어떻게 실행되어야 하는지와 관리 스타일이 어떠해야 하는지에 대한 근본적인 이념적 차이가 있다는 것입니다.

그러나 이 질문에 답하려면 다음과 같이 하십시오.

Linux를 이런 혼란에 빠뜨리는 것은 디자인 결함이 아니라 디자인 선택입니다. 기본값에 대해 논쟁을 벌일 수 있지만 Unix는 관리자가 이해할 수 있도록 설계되었습니다.정확히시스템이 수행하는 작업. "이것은 Unix가 수행하는 방식입니다."는 대상 작업 환경에서 허용되는 대답이 아닙니다. 당신의 상사는 당신이 문제가 발생했을 때 무슨 일이 일어났는지 정확히 알고 문제의 근본 원인을 해결하여 다시는 그런 일이 일어나지 않도록 했다는 확신을 갖기를 원할 것입니다.

관리자는 불투명하고 자동화된 플랫폼 프로세스의 명확성과 시스템 관성을 중요하게 여기기 때문에 구현하려는 솔루션을 결정하는 것은 관리자의 몫입니다. ?). Unix/Linux는 작업을 완료하기 위한 기본 메커니즘을 제공하지만(이러한 메커니즘이 중복되거나 "건조한" 등을 방지할 수 있기를 바랍니다) 최종 솔루션을 개발하려고 하지는 않습니다.

커널 메커니즘을 연구하는 데 관심이 있을 수 있습니다.OOM 킬러이렇게 하면 시스템 전체 또는 프로세스별로 런어웨이 프로세스가 종료됩니다(이 작업을 수행하는 방법을 알아보려면 이전 점프를 참조하세요).그룹 C현재는 리소스 사용을 제어하는 ​​데 선호되는 메커니즘이지만제한.conf꽤 오랫동안 사용되어 왔으며 사용자 이름이나 그룹 멤버십을 기준으로 제한을 설정할 수 있습니다(단, 세션별로 적용됩니다).

특정 사용자나 그룹이 시스템을 교착 상태로 만드는 경우 공급업체 측의 설계 가정은 다음과 같습니다.생각하다프로세스에 제한을 가하여(아마도 일시적인 급증을 적절하게 수용하거나 애플리케이션 성능/동작이 저하될 수 있는 애플리케이션에 대한 제한적인 한도를 피하여 시스템에서 더 많은 성능을 짜내기 위해) 프로세스가 OOM 종료에 도달하도록 허용합니다. 한계.

그렇지 않은 경우, 이 문제를 일으키는 모든 소프트웨어가 포함되어 시스템이 충돌하지 않도록 cgroups 또는limit.conf로 작업을 수행해야 합니다. 이는 실제로 옵트인 또는 옵트아웃 기능을 제공하지 않는 Windows에서 기대하는 것과 반대됩니다.그냥 해한 가지 방법으로, 그것이 당신의 사고 방식이나 비즈니스 프로세스에 맞지 않는다면, 당신은 그것을 다루는 방법을 배워야 합니다. 많은 Windows의 디자인은 괜찮은 관리자의 의도적인 디자인 선택을 숨기고 기술 지식이 없는 사람들에게 (진심으로) "이것은 시스템이 작동하는 방식이 아닙니다" 또는 "이것은 컴퓨터가 작동하는 방식이 아닙니다"라고 말합니다. 죽이는 논리는 관리자에게 책임을 지도록 권장합니다.

궁극적으로 문제를 해결하는 것뿐만 아니라 문제를 통제하고 제거하는 데도 관심을 기울여야 합니다. 플랫폼 설계의 경우 Xorg와 그 하위 항목을 일종의 기본 cgroup에 추가하여 대상으로 삼을 수 있다는 주장이 있지만 이를 Canonical과 결합해야 합니다(이것은 Ubuntu에 있다고 가정합니다( 다른 의견에서 얻은 것)). 이 문제가 발생하는 몇 가지 근본 원인이 있으며 다음 방법 중 하나로 해결해야 합니다. 1) 추가 하드웨어 용량 2) 해당 용량에 대한 애플리케이션 액세스 제한/할당 3) 메모리 누수 또는 소프트웨어 버그와 같은 애플리케이션 수준 오류 해결 .

시스템 복구를 위해 특정 tty를 생성한다는 Hauke의 아이디어는 실제로 당신이 좋아한다고 말한 것을 고려하면 매우 좋은 아이디어입니다. 목표에 더 가까워지기 위해 위의 내용에 부록을 추가했습니다. 이는 스스로 개발할 수 있는 특정 솔루션이지만 스스로 알아낼 수 있는 순열은 거의 무한합니다.

getties 중 하나에 CPU 및 I/O 실시간 우선순위를 부여하면 문제가 줄어들 수 있습니다. UID 0으로 다른 사용자를 생성하고 해당 사용자의 쉘을 정적 링크 쉘이 있는 램디스크에 대한 경로로 만들 수도 있습니다. 그리고 /etc/passwd캐시에 보관하려면 몇 초마다 계속 읽어보세요.

더 나은 접근 방식은 많은 RAM을 소비하는 프로세스를 중지하는 프로세스를 실행하는 것입니다.

편집 1:

또 다른 아이디어: 화면 내의 가상 콘솔에서 루트로 top을 시작하고(둘 다 실시간 우선순위로) 자동으로 화면을 잠글 수 있습니다. 그래서 top을 사용하려면 루트 비밀번호가 필요하지만, 필요한 프로세스가 이미 실행되고 있다는 장점이 있습니다. 적극적으로 무언가를 하고 있기 때문에 교체되지는 않지만 CPU와 메모리를 거의 소비하지 않습니다.

알다시피 SysRq는 여전히 응답하며 문제가 있는 프로세스의 OOM 우선 순위를 조정할 수 있습니다. 조정은 을 작성하여 수행됩니다 /proc/XYZ/oom_score_adj. 여기서 XYZ는 프로세스 ID입니다. 프로세스가 제어를 벗어나면 필요한 경우 AltGr++를 사용하여 SysRq프로세스 중 하나를 종료하세요.F

이 작업을 수행하는 스크립트는 다음과 같습니다.

#!/bin/bash

# match any process containing "thunderb" or "chrome" - that's specific enough for me
for i in `ps ax | grep -E 'thunderb|chrome' | cut -f1 "--delimiter= "` ; do
        fname=/proc/$i/oom_score_adj
        if [ -f "$fname" ] ; then
                # the higher the score, the more likely the process is 
                #  to be chosen by the OOM killer
                echo '900' > $fname
        fi
done

이 스크립트는 루트로 실행해야 하며 기존 프로세스에만 영향을 미칩니다.