자동화 팁. 1s 8 자동화를 위한 팁은 느리게 작동합니다.

이 기사에서는 1C 속도가 느려지면 1C가 정지되고 1C가 느리게 작동하는 주요 요인에 대해 설명합니다. 데이터는 1C + MS SQL 조합을 기반으로 구축된 대규모 IT 시스템을 최적화하는 SoftPoint의 다년간의 경험을 바탕으로 작성되었습니다.

우선 1C가 동시 작동용이 아니라는 신화에 주목할 가치가 있습니다. 많은 분량이러한 게시물에서 모든 것을 그대로 두는 이유와 확신을 찾는 포럼 사용자의 적극적인 지원을 받는 사용자입니다. 충분한 인내심과 지식이 있으면 원하는 수의 사용자에게 시스템을 제공할 수 있습니다. 느린 작동과 1C의 정지는 더 이상 문제가 되지 않습니다.

실습에서: 가장 쉬운 최적화 방법은 1C v7.7입니다(애플리케이션이 3개의 링크로 구성되어 있으므로 1C 8.1, 1C 8.2, 1C 8.3의 최적화는 더 어려운 작업입니다). 최대 400명의 동시 사용자를 확보하는 것은 상당히 일반적인 프로젝트입니다. 1500까지는 이미 어렵고 노력이 필요합니다.

두 번째 신화: 1C의 성능을 향상하고 1C 정지를 제거하려면 더 강력한 서버를 설치해야 합니다. 일반적으로 최적화 프로젝트에서는 95%의 경우 업그레이드 없이도 또는 RAM을 추가하는 등 장비의 사소한 부분을 업데이트하여 허용 가능한 성능을 달성할 수 있습니다. 장비는 여전히 서버 기반이어야 하며, 특히 디스크 하위 시스템은 더욱 그렇습니다. 오래된 디스크 하위 시스템은 1C가 느리게 작동하는 이유 중 하나일 뿐입니다.

1C에서 다중 사용자 작업 시 주요 제한 사항은 잠금 메커니즘입니다. 일반적으로 많은 사람들이 데이터베이스에서 작업하는 것을 방해하는 것은 서버 장비가 아닌 1C의 차단입니다. 이 문제를 극복하려면 열심히 노력하고 1C의 잠금 논리를 변경해야 합니다. 테이블 형식에서 행 기반으로 낮추십시오. 예를 들어, 문서를 게시하면 시스템의 모든 문서가 아닌 하나만 차단됩니다.

그림 1. 1C 사용자, 구성 모듈 및 이 모듈의 특정 코드 줄에 대한 정보가 포함된 PerfExpert 모니터링 시스템의 1C 차단 대기열.

1C 잠금 메커니즘을 변경하는 것은 매우 복잡한 기술입니다. 모든 사람이 그러한 트릭을 수행할 수 있는 것은 아니며 구조를 최적화하고 작업 실행 시간을 단축하는 방법은 단 하나뿐입니다. 사실 1C의 차단과 작업 실행 시간은 상호 연관된 지표입니다. 예를 들어 문서 게시 작업에 15초가 소요되는 경우 사용자 수가 많으면 전송 중에 다른 사람이 문서 게시를 시도하고 차단을 기다릴 확률이 높습니다. 실행 시간을 1초 이상으로 늘리면 이 작업에 대한 1C 차단이 크게 줄어듭니다.

차단의 관점에서 볼 때 더 위험한 것은 그룹 처리로, 완료하는 데 오랜 시간이 걸리고 동시에 1C 차단이 발생할 수 있습니다. 문서의 순서 또는 일괄 처리 복원과 같이 데이터를 변경하는 모든 처리는 테이블을 잠그고 다른 사용자가 문서를 게시하는 것을 방지합니다. 당연히 이러한 처리가 빠르게 수행될수록 차단 시간이 단축되고 사용자가 더 쉽게 처리할 수 있습니다.

읽기 전용 작업을 수행하는 무거운 보고서는 데이터를 잠그지 않는 것처럼 보이지만 잠금 측면에서 위험할 수도 있습니다. 이러한 보고서는 1C의 차단 강도에 영향을 주어 시스템의 다른 작업 속도를 저하시킵니다. 즉, 보고서가 매우 무겁고 서버 리소스의 대부분을 차지하는 경우 보고서가 시작되기 전에는 동일한 작업이 1초 동안 수행되었고 보고서 실행 중에는 15초 동안 수행된 것으로 나타날 수 있습니다. . 당연히 작업 실행 시간이 길어질수록 차단 강도도 높아집니다.

그림 2. 모든 사용자로부터 구성 모듈 측면에서 작업 서버에 로드합니다. 각 모듈에는 고유한 색상이 있습니다. 1C에서 생성된 부하에는 분명한 불균형이 있습니다.

최적화의 기본 규칙은 문서 처리에 최소한의 시간이 소요되고 필요한 작업만 수행되어야 한다는 것입니다. 예를 들어 레지스터 계산은 필터링 조건을 지정하지 않고 게시 처리에 사용되는 경우가 많습니다. 이 경우 필터링 조건에 따라 레지스터에 적절한 인덱스가 있어야 한다는 점을 잊지 않고 최상의 선택성을 얻을 수 있도록 레지스터에 대한 필터를 지정해야 합니다.

무거운 보고서를 실행하는 것 외에도 MS SQL 및 MS Windows의 최적이 아닌 설정은 작업 실행 시간을 늦추고 따라서 1C 차단 강도를 높일 수 있습니다. 이 문제는 95%의 클라이언트에서 발생합니다. 이들은 심각한 조직의 서버이며, 우수한 자격을 갖춘 관리자로 구성된 전체 부서가 지원 및 구성에 참여하고 있습니다.

잘못된 서버 구성의 주된 이유는 관리자가 실행 중인 서버에서 무엇이든 변경할 수 있다는 두려움과 "최고는 좋은 것의 적이다"라는 규칙 때문입니다. 관리자가 서버 설정을 변경하고 문제가 시작되면 당국의 모든 분노는 부주의한 관리자에게 쏟아질 것입니다. 그러므로 자신의 책임을 실험하는 것보다 모든 것을 그대로두고 상사의 명령 없이는 한 걸음도 떼지 않는 것이 더 유익합니다.

두 번째 이유는 네트워크 최적화 문제에 대한 명확한 정보가 부족하기 때문입니다. 종종 서로 완전히 모순되는 의견이 많이 있습니다. 최적화에 전념하는 모든 의견에는 이를 옹호할 반대자와 광신자가 있습니다. 결과적으로 인터넷과 포럼은 도움을 주기보다는 서버 설정을 혼란스럽게 할 가능성이 더 높습니다. 이러한 불확실한 상황에서 관리자는 서버에서 제대로 작동하는 항목을 변경하려는 욕구가 더욱 줄어듭니다.

언뜻보기에 그림은 분명합니다. 1C 서버의 작동 속도를 늦추는 모든 것을 최적화해야합니다. 그러나 그러한 최적화 프로그램 대신에 우리 자신이 있다고 상상해 봅시다. 1C 8.1 8.2 8.3 UPP가 있고 50명의 사용자가 동시에 작업하고 있다고 가정해 보겠습니다. 어느 끔찍한 날, 사용자들은 1C가 느리다고 불평하기 시작했고, 우리는 이 문제를 해결해야 합니다.

우선, 우리는 서버에서 무슨 일이 일어나고 있는지 살펴봅니다. 특히 독립적인 바이러스 백신이 시스템 전체 검사를 수행하는 경우 어떻게 될까요? 검사 결과 모든 것이 괜찮은 것으로 나타났습니다. 서버는 sqlservr 프로세스에 의해서만 100% 로드되었습니다.

실제로: 하급 관리자 중 한 명이 자신의 주도로 서버에서 자동 업데이트를 켜고 Windows 및 SQL이 행복하게 업데이트되었으며 업데이트 후 1C 사용자 작업의 엄청난 속도 저하가 시작되거나 1C가 단순히 정지되었습니다.

다음 단계는 어떤 프로그램이 MS SQL을 로드하는지 확인하는 것입니다. 검사 결과 로드는 약 20개의 애플리케이션 서버 연결에 의해 생성되는 것으로 나타났습니다.

실제 사례: 웹 사이트의 데이터를 즉시 업데이트하는 프로그램이 루프에 빠졌고, 4시간마다 한 번씩 업데이트하는 대신 중단 없이 지속적으로 수행하여 서버에 과도한 부하를 주고 데이터를 차단했습니다.

상황에 대한 추가 분석은 큰 어려움에 직면합니다. 우리는 로드가 1C에서 직접 발생한다는 것을 이미 알아냈지만 사용자가 정확히 무엇을 하고 있는지 어떻게 이해할 수 있습니까? 아니면 적어도 그들이 누구인지. 조직에 10명의 1C 사용자가 있으면 그들을 살펴보고 그들이 지금 무엇을 하고 있는지 알아낼 수 있으면 좋지만 우리의 경우에는 50명이 있고 여러 건물에 흩어져 있습니다.

우리가 고려하고 있는 예에서 상황은 아직 복잡하지 않습니다. 경기 둔화가 오늘이 아니라 어제였다고 상상해 보세요. 오늘은 상황이 반복되지 않고 모든 것이 괜찮지만 교환원이 어제 일을 할 수 없었던 이유를 알아내야 합니다. (그들은 아무것도 없다는 사실 때문에 하루 종일 채팅하는 것을 좋아하기 때문에 집을 떠나기 전에 자연스럽게 불평했습니다. 일하는 것, 일하는 것 이상). 이 사례는 서버 작동의 주요 매개변수 기록을 항상 유지하고 이벤트 순서를 복원할 수 있는 서버 로깅 시스템의 필요성을 강조합니다.

로깅 시스템은 단순히 시스템 최적화에 없어서는 안 될 도구입니다. 여기에 현재 상태를 온라인으로 볼 수 있는 기능을 추가하면 서버 상태 모니터링 시스템을 얻게 됩니다. 모든 최적화 프로젝트는 병목 현상을 식별하기 위해 서버 상태 통계를 수집하는 것부터 시작됩니다.

우리가 최적화 분야에 일을 시작했을 때 많은 서버 모니터링 시스템을 시도했지만 안타깝게도 이 문제를 적절한 수준에서 해결하는 방법을 찾을 수 없었기 때문에 자체적으로 시스템을 만들어야 했습니다. 그 결과 IT 시스템 최적화 프로세스를 자동화하고 합리화할 수 있는 고유한 제품인 PerfExpert가 탄생했습니다. 이 프로그램은 1C와의 긴밀한 통합, 눈에 띄는 추가 부하 없음, 전투 상황에서의 실제 사용에 대한 반복적으로 입증된 적합성으로 구별됩니다.

우리의 예로 돌아가면, 가장 가능성 있는 결과는 다음과 같습니다: 관리자가 "구성을 작성한 것은 프로그래머들입니다."라고 말하면 프로그래머는 "모든 것이 우리를 위해 잘 작성되었습니다. 서버가 제대로 작동하지 않습니다."라고 대답합니다. 그리고 그들이 말하는 카트는 아직 거기에 있습니다. 결과적으로 1C는 속도가 느려지거나 정지되거나 느리게 작동합니다.

어쨌든 1C 성능 문제를 해결하려면 먼저 성능 모니터링을 구입하여 사용하는 것이 좋습니다성능전문가 , 이를 통해 올바른 관리 결정을 내리고 비용을 절약할 수 있습니다. 이 제품은 최대 50명의 사용자가 있는 소규모 1C:Enterprise IS와 1000명의 사용자가 있는 시스템에 모두 적합합니다. 2015년 7월부터 실적 모니터링성능전문가 1C:호환 인증서를 받고 테스트를 통과했습니다.마이크로소프트 1C 시스템뿐만 아니라 다음을 기반으로 하는 다른 정보 시스템의 성능 문제를 해결하는 데 도움이 됩니다. MS SQL Server(Axapta, CRM Dynamics, Doc Vision 및 기타).

정보가 마음에 들면 추가 조치를 권장합니다.

- 1C 성능(1C 7.7, 1C 8.1, 1C 8.2,1C 8.3) 및 기타 정보 시스템, 그런 다음 연감(블록 및 교착 상태, 엄청난 압력 CPU 및 디스크, 데이터베이스 유지 관리 및 인덱스 튜닝 - 전용 작은 부분거기에서 찾을 수 있는 기술 자료).
.
- 전문가와 성능 문제를 논의하고 싶거나 PerfExpert 성능 모니터링 솔루션을 주문하려는 경우, 요청을 남겨주시면 최대한 빨리 연락드리겠습니다.

여러 가지 이유로 1C 프로그램 사용자는 때때로 1C 성능 문제에 직면합니다. 예를 들어 문서를 처리하는 데 오랜 시간이 걸리고, 보고서를 생성하는 데 오랜 시간이 걸리고, 트랜잭션 오류, 프로그램이 정지되고, 사용자 작업에 대한 느린 응답 등이 있습니다. 지침을 따르면 프로그램 성능에 있어서 상당한 성공을 거두고 시스템 제한 초과를 방지할 수 있습니다. 이것이 모든 질병에 대한 만병통치약은 아니지만, 1C 둔화의 대부분의 이유는 바로 이러한 문제에 있습니다.

1. 사용자가 작업하는 동안 일상적인 작업이나 백그라운드 작업을 수행하지 마세요.

시스템 관리자의 첫 번째이자 주요 규칙은 모든 백그라운드 작업이 근무 시간 외에 완료되도록 예약하는 것입니다. 일상적인 작업(인덱싱, 문서 처리, 데이터 업로드)을 수행하는 동시에 사용자의 작업을 방해하지 않도록 시스템을 최대한 언로드해야 합니다. 시스템이나 사용자가 서로 다른 시간에 작업하더라도 서로 간섭하지 않습니다.

2. 사용자의 근무 시간 중에는 RIB 데이터를 교환하지 마십시오.

최근 기업들이 온라인 모드와 터미널 액세스를 선호하여 RIB 데이터 교환 시스템을 포기하고 있지만, 교환 데이터를 업로드 및 다운로드하는 동안 문서를 수행하고 프로그램에서 완전히 작업하는 것이 불가능하다는 점을 기억하는 것은 실수가 아닙니다. 가능하다면 이 절차는 밤에 백그라운드 작업을 사용하여 수행해야 합니다.

3. 적시에 PC 성능을 향상하여 실제 요구 사항에 맞게 성능을 조정합니다.

시스템에서 30명과 100명의 사용자가 동시에 작업하면 다른 부하가 발생한다는 점을 잊지 마십시오. 따라서 사용자의 양적 증가가 계획된 경우 IT 서비스는 회사 경영진과 함께 기계 제품군 확장, 추가 메모리 또는 서버 구매 문제를 즉시 고려해야 합니다.

4. 1C가 실행되는 소프트웨어

1C 프로그램은 운영 체제에서 다르게 작동합니다. 이유는 정확히 알 수 없지만 그렇습니다. 예를 들어 SQL Postgre와 함께 Linux OS에서 1C 데이터베이스의 서버 버전은 MS SQL과 함께 Windows OS에서 동일한 1C 데이터베이스보다 훨씬 느립니다. 이 사실에 대한 정확한 이유는 알려지지 않았지만 분명히 1C 플랫폼 깊은 곳에 호환성 문제가 있습니다. 운영체제 Microsoft 이외의 DBMS. 데이터베이스에 상당한 부하를 가할 계획이라면 64비트 서버에 시스템을 배포하는 것도 좋습니다.

5. 데이터베이스 인덱싱

내부에서 시스템을 "빗질"하는 1C 프로그램의 내부 절차. 밤에 백그라운드 루틴 작업으로 실행되도록 설정하고 조용하게 유지하세요.

6. 운영 일괄 회계 비활성화

사실 문서의 운영 처리 중에 이동은 일괄 회계 레지스터를 포함한 레지스터에 기록됩니다. 프로그램 설정에서 문서 게시 시 일괄 회계 기록 기록을 비활성화할 수 있습니다. 한 달에 한 번, 예를 들어 데이터베이스 부하가 가장 적거나 작업하는 사용자 수가 가장 적은 시간에 일괄적으로 문서 게시 처리를 시작해야 합니다.

7. 램

다음 수식을 사용하십시오.

RAM = (DB 1+DB 2+DB N) / 100 * 70

데이터베이스 전체 물리적 볼륨의 약 70%입니다. 1C 데이터베이스는 RAM을 잘 활용하는 것을 좋아합니다. 이것을 잊지 마세요.

8. 가능하다면 불완전하고 오래된 코드를 사용하여 자체 작성 보고서 및 처리를 최적화하세요.

기업이 운영되는 동안 보고서 작성 및 처리는 물론 비즈니스 프로세스 관리 및 특정 정보 추출을 위한 개선이 필요합니다. 이러한 모든 개선 사항으로 인해 결함이 발생하고 작업 속도가 느려질 수 있습니다. 왜냐하면... a) 일부 Kulibin은 프로그램 실행이 어렵고 실행에 상당한 노력이 필요한 무겁고 잘못된 코드를 한 번 작성했을 수 있습니다. b) 처리 또는 보고서가 작성된 코드가 더 이상 사용되지 않으며 수정 및 재프로그래밍이 필요할 수 있습니다. 규칙을 사용하십시오. 프로그램에서 무언가를 덜 변경할수록 좋습니다.

9. 캐시 지우기

정기적으로 서버를 재부팅하면 오래된 1C 캐시 문제가 해결되는 경우가 있습니다. 그냥 시도 해 봐. 언로드도 도움이 될 수 있습니다. 구성자를 통해 정보 베이스를 로드하는 것입니다. 그리고 가장 최근에 특정 사용자의 캐시를 정리하면 kexifzghjuhfv8j33hbdgk0 형식의 1C 시스템 디렉터리에서 폴더가 삭제됩니다. 하지만 캐시된 사용자 폴더를 삭제하는 것은 마지막 작업입니다. 왜냐하면... 캐시를 지우면 가비지 제거 외에도 저장된 보고서 설정 및 사용자 메뉴 인터페이스가 삭제되는 불쾌한 결과가 발생합니다.

10. 데이터베이스의 물리적 볼륨 줄이기

더 많은 기반은 더 많은 자원을 의미합니다. 당연히. 표준 1C 도구를 사용하여 데이터베이스를 축소합니다. 생산성 향상을 위해 5년간의 데이터를 포기할 가능성을 생각해 보십시오. 그리고 지난 5년간의 데이터가 여전히 필요한 경우 언제든지 데이터베이스 복사본을 사용할 수 있습니다.

11. 아키텍처의 올바른 구성

일반적으로 기업 정보 시스템의 아키텍처는 정확해야 합니다. 올바른 시스템이란 무엇을 의미합니까? 시스템에 할당된 작업과 사용 가능한 장비 및 소프트웨어의 비교. 시스템 관리자(기계 제품군을 알고 있기 때문에), 1C 프로그래머(1C의 리소스 요구 사항을 알고 있기 때문에) 및 회사 책임자(회사의 미래 성장 또는 축소에 대해 알고 있기 때문에)와 함께 시스템을 계획합니다. ).

최근 사용자와 관리자는 관리되는 응용 프로그램을 기반으로 개발된 새로운 1C 구성이 느리게 작동하고 경우에 따라 용납할 수 없을 정도로 느리다는 불만을 점점 더 많이 제기하고 있습니다. 새로운 구성에는 새로운 기능과 성능이 포함되어 있으므로 리소스가 더 많이 요구된다는 것은 분명하지만 대부분의 사용자는 파일 모드에서 1C 작동에 주로 영향을 미치는 것이 무엇인지 이해하지 못합니다. 이 격차를 바로잡도록 노력해보자.

우리는 이미 디스크 하위 시스템 성능이 1C 속도에 미치는 영향을 다루었지만 이 연구는 별도의 PC 또는 터미널 서버에서 응용 프로그램의 로컬 사용에 관한 것입니다. 동시에 대부분의 소규모 구현에는 사용자의 PC 중 하나가 서버로 사용되는 네트워크를 통한 파일 데이터베이스 작업이나 일반 컴퓨터 기반의 전용 파일 서버 작업이 포함됩니다.

1C의 러시아어 리소스에 대한 소규모 연구에 따르면 이 문제는 부지런히 방지되며 문제가 발생하면 일반적으로 클라이언트-서버 또는 터미널 모드로 전환하는 것이 좋습니다. 또한 관리되는 애플리케이션의 구성이 평소보다 훨씬 느리게 작동한다는 사실이 거의 일반적으로 받아들여지고 있습니다. 일반적으로 주장은 "철"입니다: "회계 2.0은 방금 날아갔고 "트로이카"는 거의 움직이지 않았습니다. 물론 이 말에는 어느 정도 진실이 있으므로 알아내려고 노력해 보겠습니다.

자원 소비, 한눈에 보기

이 연구를 시작하기 전에 우리는 관리되는 애플리케이션 기반 구성이 실제로 기존 구성보다 느린지 여부와 성능에 주요 영향을 미치는 특정 리소스를 찾는 두 가지 목표를 세웠습니다.

테스트를 위해 각각 Windows Server 2012 R2 및 Windows 8.1을 실행하는 두 개의 가상 머신을 사용하여 호스트 Core i5-4670의 코어 2개와 평균 사무용 머신에 해당하는 2GB RAM을 제공했습니다. 서버는 2개의 RAID 0 어레이에 배치되었고 클라이언트는 유사한 범용 디스크 어레이에 배치되었습니다.

실험적 기반으로 Accounting 2.0 릴리스의 여러 구성을 선택했습니다. 2.0.64.12 , 이후 다음으로 업데이트되었습니다. 3.0.38.52 , 모든 구성이 플랫폼에서 시작되었습니다. 8.3.5.1443 .

가장 먼저 관심을 끄는 것은 Troika의 정보 기반 크기가 크게 증가했다는 점과 RAM에 대한 수요가 훨씬 더 커졌다는 점입니다.

우리는 "왜 이 세 개에 그걸 추가했지?"라는 일반적인 말을 들을 준비가 되어 있지만 서두르지는 말자. 어느 정도 자격을 갖춘 관리자가 필요한 클라이언트-서버 버전 사용자와 달리 파일 버전 사용자는 데이터베이스 유지 관리에 대해 거의 생각하지 않습니다. 또한 이러한 데이터베이스를 서비스(읽기 업데이트)하는 전문 회사의 직원은 이에 대해 거의 생각하지 않습니다.

한편 1C 정보 기반은 자체 형식의 본격적인 DBMS로 유지 관리가 필요하며 이를 위해 다음과 같은 도구도 있습니다. 정보 기반 테스트 및 수정. 어쩌면 그 이름은 잔인한 농담을 했을 수도 있습니다. 이는 이것이 문제 해결을 위한 도구임을 암시하지만 낮은 성능도 문제이며 테이블 압축과 함께 구조 조정 및 재인덱싱은 모든 DBMS 관리자를 위한 데이터베이스 최적화를 위한 잘 알려진 도구입니다. . 확인해볼까요?

선택한 작업을 적용한 후 데이터베이스는 급격히 "무게를 잃어"아무도 최적화하지 않은 "2"보다 훨씬 작아졌으며 RAM 소비도 약간 감소했습니다.

이후 새로운 분류자와 디렉토리를 로딩하고, 인덱스를 생성하는 등의 작업을 수행합니다. 베이스의 크기는 증가하며 일반적으로 "3" 베이스는 "2" 베이스보다 큽니다. 그러나 이것은 더 중요하지 않습니다. 두 번째 버전이 150-200MB의 RAM으로 만족했다면 새 버전에는 0.5GB가 필요하며 프로그램 작업에 필요한 리소스를 계획할 때 이 값을 고려해야 합니다.

그물

네트워크 대역폭은 가장 중요한 매개변수특히 파일 모드의 1C와 같은 네트워크 애플리케이션의 경우 네트워크를 통해 상당한 양의 데이터를 이동합니다. 대부분의 소규모 기업의 네트워크는 저렴한 100Mbit/s 장비를 기반으로 구축되므로 100Mbit/s와 1Gbit/s 네트워크에서 1C 성능 지표를 비교하는 것부터 테스트를 시작했습니다.

네트워크를 통해 1C 파일 데이터베이스를 시작하면 어떻게 되나요? 클라이언트는 상당히 많은 양의 정보를 임시 폴더에 다운로드합니다. 특히 이것이 첫 번째 "콜드" 시작인 경우에는 더욱 그렇습니다. 100Mbit/s에서는 채널 폭에 도달할 것으로 예상되며 다운로드하는 데 상당한 시간이 걸릴 수 있습니다. 우리의 경우 약 40초입니다(그래프를 나누는 데 드는 비용은 4초입니다).

두 번째 실행은 일부 데이터가 캐시에 저장되고 재부팅할 때까지 남아 있기 때문에 더 빠릅니다. 기가비트 네트워크로 전환하면 "콜드"와 "핫" 모두에서 프로그램 로딩 속도가 크게 향상될 수 있으며 값의 비율이 존중됩니다. 따라서 우리는 각 측정값의 가장 큰 값을 100%로 하여 결과를 상대값으로 표현하기로 결정했습니다.

그래프에서 볼 수 있듯이 Accounting 2.0은 모든 네트워크 속도에서 두 배 빠른 속도로 로드되며, 100 Mbit/s에서 1 Gbit/s로 전환하면 다운로드 시간을 4배 단축할 수 있습니다. 이 모드에서는 최적화된 데이터베이스와 최적화되지 않은 "트로이카" 데이터베이스 사이에 차이가 없습니다.

또한 그룹 전송 등의 무거운 모드에서 네트워크 속도가 작동에 미치는 영향을 확인했습니다. 결과는 상대값으로도 표현됩니다.

여기서 더 흥미로운 점은 100 Mbit/s 네트워크에서 "3"의 최적화된 기반이 "2"와 동일한 속도로 작동하고 최적화되지 않은 기반이 두 배 더 나쁜 결과를 보여준다는 것입니다. 기가비트에서는 비율이 동일하게 유지되고 최적화되지 않은 "3"도 "2"보다 절반 느리고 최적화된 비율은 1/3만큼 뒤쳐집니다. 또한 1Gbit/s로의 전환을 통해 실행 시간을 2.0 버전에서는 3배, 3.0 버전에서는 절반으로 줄일 수 있습니다.

일상 업무에 대한 네트워크 속도의 영향을 평가하기 위해 우리는 다음을 사용했습니다. 성능 측정, 각 데이터베이스에서 미리 결정된 일련의 작업을 수행합니다.

실제로 일상적인 작업의 경우 네트워크 처리량은 병목 현상이 아니며 최적화되지 않은 "3"은 "2"보다 20%만 느리고 최적화 후에도 거의 동일하게 빨라지는 것으로 나타났습니다. 씬 클라이언트 모드에서 작업할 때의 이점 분명합니다. 1Gbit/s로의 전환은 최적화된 베이스에 아무런 이점을 주지 않으며, 최적화되지 않은 베이스와 둘 사이에 작은 차이를 보이면서 더 빠르게 작동하기 시작합니다.

수행된 테스트를 통해 네트워크가 새로운 구성에 대한 병목 현상이 아니며 관리되는 애플리케이션이 평소보다 훨씬 빠르게 실행된다는 것이 분명해졌습니다. 또한 과중한 작업과 데이터베이스 로딩 속도가 중요한 경우 1Gbit/s로 전환하는 것이 좋습니다. 다른 경우에는 새로운 구성을 통해 느린 100Mbit/s 네트워크에서도 효과적으로 작업할 수 있습니다.

그렇다면 1C가 느린 이유는 무엇입니까? 더 자세히 살펴보겠습니다.

서버 디스크 하위 시스템 및 SSD

이전 기사에서는 SSD에 데이터베이스를 배치하여 1C 성능을 향상시켰습니다. 서버의 디스크 하위 시스템 성능이 부족할까요? 두 개의 데이터베이스를 동시에 실행하는 그룹 동안 디스크 서버의 성능을 측정한 결과 다소 낙관적인 결과를 얻었습니다.

IOPS(초당 입출력 작업 수)가 913으로 상대적으로 높음에도 불구하고 대기열 길이는 1.84를 초과하지 않았습니다. 좋은 결과. 이를 바탕으로 일반 디스크로 만든 미러는 헤비 모드에서 8~10개의 네트워크 클라이언트가 정상적으로 작동하는 데 충분하다고 가정할 수 있습니다.

그렇다면 서버에 SSD가 필요합니까? 이 질문에 답하는 가장 좋은 방법은 유사한 방법을 사용하여 수행한 테스트를 통해서입니다. 네트워크 연결은 어디에서나 1Gbit/s이며 결과도 상대 값으로 표현됩니다.

데이터베이스 로딩 속도부터 시작해 보겠습니다.

일부 사람들에게는 놀랍게 보일 수도 있지만 서버의 SSD는 데이터베이스 로딩 속도에 영향을 미치지 않습니다. 이전 테스트에서 알 수 있듯이 여기서 주요 제한 요소는 네트워크 처리량과 클라이언트 성능입니다.

다시 실행해 보겠습니다.

위에서 우리는 이미 무거운 모드에서 작업하는 경우에도 디스크 성능이 상당히 충분하므로 SSD의 최적화되지 않은 기반을 제외하고 SSD의 속도도 영향을 받지 않는다는 점을 이미 언급했습니다. 실제로 이는 최적화 작업이 데이터베이스의 정보를 구성하여 임의 I/O 작업 수를 줄이고 이에 대한 액세스 속도를 높인다는 것을 다시 한 번 확인시켜 줍니다.

일상적인 작업에서는 그림이 비슷합니다.

최적화되지 않은 데이터베이스만 SSD의 이점을 누릴 수 있습니다. 물론 SSD를 구매할 수도 있지만 데이터베이스를 적시에 유지 관리하는 것을 생각하는 것이 훨씬 더 나을 것입니다. 또한 서버의 정보베이스가 있는 섹션 조각 모음을 잊지 마세요.

클라이언트 디스크 하위 시스템 및 SSD

우리는 SSD가 로컬에 설치된 1C의 작동 속도에 미치는 영향을 분석했으며, 언급된 내용의 대부분은 네트워크 모드에서 작업할 때도 마찬가지입니다. 실제로 1C는 백그라운드 및 일상적인 작업을 포함하여 디스크 리소스를 매우 적극적으로 사용합니다. 아래 그림에서는 Accounting 3.0이 로딩 후 약 40초 동안 디스크에 적극적으로 액세스하는 모습을 볼 수 있습니다.

그러나 동시에 하나 또는 두 개의 정보 데이터베이스를 사용하여 활발한 작업을 수행하는 워크스테이션의 경우 일반 대량 생산 HDD의 성능 리소스로 충분하다는 점을 알아야 합니다. SSD를 구입하면 일부 프로세스 속도가 빨라질 수 있지만, 예를 들어 다운로드가 네트워크 대역폭에 의해 제한되기 때문에 일상적인 작업에서는 급격한 가속화를 느끼지 못할 것입니다.

느린 HDD일부 작업 속도가 느려질 수 있지만 그 자체만으로는 프로그램 속도가 느려질 수는 없습니다.

램

RAM이 터무니없이 저렴하다는 사실에도 불구하고 많은 워크스테이션은 구입 시 설치된 메모리 용량으로 계속 작동합니다. 여기에 첫 번째 문제가 기다리고 있습니다. 평균 "트로이카"에는 약 500MB의 메모리가 필요하다는 사실을 토대로 프로그램을 사용하는 데 총 1GB의 RAM 용량으로는 충분하지 않다고 가정할 수 있습니다.

우리는 시스템 메모리를 1GB로 줄이고 두 개의 정보 데이터베이스를 시작했습니다.

언뜻 보면 모든 것이 그렇게 나쁘지 않고 프로그램이 식욕을 억제하고 사용 가능한 메모리에 잘 들어맞지만 운영 데이터의 필요성은 변하지 않았으므로 어디로 갔습니까? 디스크, 캐시, 스왑 등에 덤프하는 이 작업의 본질은 현재 필요하지 않은 데이터를 빠른 RAM에서 전송하여 양이 충분하지 않아 디스크 메모리를 느리게 한다는 것입니다.

그것이 어디로 이어지는가? 예를 들어 한 번에 두 개의 데이터베이스에서 그룹 재전송을 시작하는 등 과도한 작업에서 시스템 리소스가 어떻게 사용되는지 살펴보겠습니다. 먼저 2GB RAM이 있는 시스템에서:

보시다시피 시스템은 데이터를 수신하기 위해 네트워크를 적극적으로 사용하고 이를 처리하기 위해 프로세서를 사용합니다. 디스크 활동은 중요하지 않습니다. 처리하는 동안 때때로 증가하지만 제한 요소는 아닙니다.

이제 메모리를 1GB로 줄여보겠습니다.

상황은 급격히 변하고 있으며 이제 주 로드는 하드 드라이브에 있고 프로세서와 네트워크는 유휴 상태이며 시스템이 디스크에서 필요한 데이터를 메모리로 읽고 불필요한 데이터를 메모리로 보낼 때까지 기다립니다.

동시에 1GB 메모리가 있는 시스템에서 두 개의 개방형 데이터베이스를 사용한 주관적인 작업조차도 매우 불편한 것으로 나타났습니다. 상당한 지연과 디스크에 대한 활성 액세스로 디렉터리와 매거진이 열렸습니다. 예를 들어, 상품 및 서비스 판매 저널을 여는 데는 약 20초가 걸렸으며 이때 내내 높은 디스크 활동이 발생했습니다(빨간색 선으로 강조 표시됨).

관리되는 애플리케이션을 기반으로 하는 구성 성능에 대한 RAM의 영향을 객관적으로 평가하기 위해 첫 번째 데이터베이스의 로딩 속도, 두 번째 데이터베이스의 로딩 속도, 데이터베이스 중 하나에서 그룹 재실행이라는 세 가지 측정을 수행했습니다. . 두 데이터베이스는 완전히 동일하며 최적화된 데이터베이스를 복사하여 생성되었습니다. 결과는 상대 단위로 표시됩니다.

결과는 그 자체로 입증됩니다. 로딩 시간이 약 1/3 정도 증가하면(여전히 허용 가능) 데이터베이스에서 작업을 수행하는 시간이 3배 증가하므로 이러한 조건에서 편안한 작업에 대해 말할 필요가 없습니다. 그건 그렇고, SSD를 구입하면 상황이 개선될 수 있지만 결과가 아닌 원인을 처리하고 적절한 양의 RAM을 구입하는 것이 훨씬 더 쉽고 저렴합니다.

RAM 부족은 새로운 1C 구성으로 작업하는 것이 불편한 주된 이유입니다. 2GB의 온보드 메모리 구성은 최소한으로 적합한 것으로 간주되어야 합니다. 동시에, 우리의 경우 "온실" 조건이 생성되었다는 점을 명심하십시오. 깨끗한 시스템, 1C 및 작업 관리자만 실행 중이었습니다. 실제 업무 컴퓨터에서는 일반적으로 브라우저, Office 제품군이 열려 있고 바이러스 백신이 실행 중이므로 데이터베이스당 500MB와 일부 예약 공간이 필요합니다. 과도한 작업 중에도 메모리 부족이나 생산성 저하가 발생하지 않습니다.

CPU

과장하지 않고 중앙 프로세서는 궁극적으로 모든 계산을 처리하므로 컴퓨터의 심장이라고 할 수 있습니다. 그 역할을 평가하기 위해 RAM과 동일한 또 다른 테스트를 수행하여 가상 머신에서 사용할 수 있는 코어 수를 2개에서 1개로 줄였으며, 테스트는 메모리 용량 1GB와 2GB로 두 번 수행되었습니다.

결과는 매우 흥미롭고 예상치 못한 것으로 나타났습니다. 리소스가 부족할 때 더 강력한 프로세서가 부하를 효과적으로 처리하고 나머지 시간에는 실질적인 이점을 제공하지 않았습니다. 1C Enterprise(파일 모드)는 프로세서 리소스를 적극적으로 사용하는 응용 프로그램이라고 할 수 없으며 다소 까다롭습니다. 그리고 어려운 상황에서는 프로세서가 애플리케이션 자체의 데이터를 계산하는 것보다 추가 입출력 작업 등 간접비를 처리하는 데 많은 부담을 지게 됩니다.

결론

그렇다면 1C가 느린 이유는 무엇입니까? 우선, RAM이 부족하기 때문에 이 경우 주요 부하는 하드 드라이브와 프로세서에 해당됩니다. 그리고 사무실 구성에서 일반적으로 발생하는 것처럼 성능이 빛나지 않으면 기사 시작 부분에 설명된 상황이 발생합니다. "2"는 제대로 작동했지만 "3"은 엄청나게 느립니다.

두 번째는 네트워크 성능입니다. 느린 100Mbit/s 채널은 실제 병목 현상이 될 수 있지만 동시에 씬 클라이언트 모드는 느린 채널에서도 상당히 편안한 수준의 작동을 유지할 수 있습니다.

그렇다면 디스크 드라이브에 주의를 기울여야 합니다. SSD를 구입하는 것은 좋은 투자가 아닐 수 있지만, 드라이브를 좀 더 현대적인 것으로 교체하는 것은 좋은 생각이 될 것입니다. 하드 드라이브 세대 간의 차이는 다음 자료를 통해 평가할 수 있습니다.

그리고 마지막으로 프로세서입니다. 물론 더 빠른 모델이 불필요한 것은 아니지만 이 PC를 그룹 처리, 무거운 보고서, 월말 마감 등 무거운 작업에 사용하지 않는 한 성능을 높이는 데 거의 의미가 없습니다.

이 자료가 "1C가 느린 이유"라는 질문을 빠르게 이해하고 추가 비용 없이 가장 효과적으로 해결하는 데 도움이 되기를 바랍니다.

태그:

보려면 JavaScript를 활성화하십시오.

특히 1c 8.3 버전으로 전환할 때 1c 속도가 느려지는 원인에 대한 질문을 자주 받습니다. Interface LLC의 동료 덕분에 다음과 같이 자세히 알려드립니다.

이전 간행물에서 디스크 하위 시스템 성능이 1C 속도에 미치는 영향에 대해 이미 다루었지만 이 연구는 별도의 PC 또는 터미널 서버에서 응용 프로그램의 로컬 사용에 관한 것입니다. 동시에 대부분의 소규모 구현에는 사용자의 PC 중 하나가 서버로 사용되는 네트워크를 통한 파일 데이터베이스 작업이나 일반 컴퓨터 기반의 전용 파일 서버 작업이 포함됩니다.

1C의 러시아어 리소스에 대한 소규모 연구에 따르면 이 문제는 부지런히 방지되며 문제가 발생하면 일반적으로 클라이언트-서버 또는 터미널 모드로 전환하는 것이 좋습니다. 또한 관리되는 애플리케이션의 구성이 평소보다 훨씬 느리게 작동한다는 사실이 거의 일반적으로 받아들여지고 있습니다. 일반적으로 주어진 주장은 "철"입니다. "회계 2.0은 방금 날아 갔지만 "트로이카"는 거의 움직이지 않았습니다." 물론이 말에는 어느 정도 진실이 있으므로 알아 내려고 노력해 보겠습니다.

자원 소비, 한눈에 보기

테스트를 위해 각각 Windows Server 2012 R2 및 Windows 8.1을 실행하는 두 개의 가상 머신을 사용하여 호스트 Core i5-4670의 코어 2개와 평균 사무용 머신에 해당하는 2GB RAM을 제공했습니다. 서버는 2개의 WD Se로 구성된 RAID 0 어레이에 배치되었고, 클라이언트는 유사한 범용 디스크 어레이에 배치되었습니다.

가장 먼저 관심을 끄는 것은 Troika의 정보 기반 크기가 크게 증가했다는 점과 RAM에 대한 수요가 훨씬 더 커졌다는 점입니다.

선택한 작업을 적용한 후 데이터베이스는 급격히 "무게를 잃어"아무도 최적화하지 않은 "2"보다 훨씬 작아졌으며 RAM 소비도 약간 감소했습니다.

그물

네트워크 대역폭은 특히 네트워크를 통해 상당한 양의 데이터를 이동하는 파일 모드의 1C와 같은 네트워크 애플리케이션의 가장 중요한 매개변수 중 하나입니다. 대부분의 소규모 기업의 네트워크는 저렴한 100Mbit/s 장비를 기반으로 구축되므로 100Mbit/s와 1Gbit/s 네트워크에서 1C 성능 지표를 비교하는 것부터 테스트를 시작했습니다.

또한 그룹 전송 등의 무거운 모드에서 네트워크 속도가 작동에 미치는 영향을 확인했습니다. 결과는 상대값으로도 표현됩니다.

그렇다면 1C가 느린 이유는 무엇입니까? 더 자세히 살펴보겠습니다.

서버 디스크 하위 시스템 및 SSD

상대적으로 많은 초당 입출력 작업 수(IOPS)(913)에도 불구하고 대기열 길이는 1.84를 초과하지 않았으며 이는 2디스크 어레이의 경우 매우 좋은 결과입니다. 이를 바탕으로 일반 디스크로 만든 미러는 헤비 모드에서 8~10개의 네트워크 클라이언트가 정상적으로 작동하는 데 충분하다고 가정할 수 있습니다.

데이터베이스 로딩 속도부터 시작해 보겠습니다.

다시 실행해 보겠습니다.

일상적인 작업에서는 그림이 비슷합니다.

클라이언트 디스크 하위 시스템 및 SSD

이전 자료에서 SSD가 로컬에 설치된 1C의 작동 속도에 미치는 영향에 대해 논의했으며, 언급된 내용의 대부분은 네트워크 모드에서 작업할 때도 마찬가지입니다. 실제로 1C는 백그라운드 및 일상적인 작업을 포함하여 디스크 리소스를 매우 적극적으로 사용합니다. 아래 그림에서는 Accounting 3.0이 로딩 후 약 40초 동안 디스크에 적극적으로 액세스하는 모습을 볼 수 있습니다.

느린 하드 드라이브로 인해 일부 작업 속도가 느려질 수 있지만 그 자체로 프로그램 속도가 느려질 수는 없습니다.

램

우리는 시스템 메모리를 1GB로 줄이고 두 개의 정보 데이터베이스를 시작했습니다.

이제 메모리를 1GB로 줄여보겠습니다.

CPU

결과는 매우 흥미롭고 예상치 못한 것으로 나타났습니다. 리소스가 부족할 때 더 강력한 프로세서가 부하를 효과적으로 처리하고 나머지 시간에는 실질적인 이점을 제공하지 않았습니다. 1C Enterprise는 프로세서 리소스를 적극적으로 사용하는 애플리케이션이라고 할 수 없으며 다소 까다롭습니다. 그리고 어려운 상황에서는 프로세서가 애플리케이션 자체의 데이터를 계산하는 것보다 추가 입출력 작업 등 간접비를 처리하는 데 많은 부담을 지게 됩니다.

결론

그렇다면 디스크 드라이브에 주의를 기울여야 합니다. SSD를 구입하는 것은 좋은 투자가 아닐 수 있지만, 드라이브를 좀 더 현대적인 것으로 교체하는 것은 좋은 생각이 될 것입니다. 하드 드라이브 세대 간의 차이는 다음 자료를 통해 평가할 수 있습니다. 두 가지 저렴한 Western Digital Blue 시리즈 드라이브 500GB 및 1TB에 대한 검토입니다.

이 자료가 "1C가 느린 이유"라는 질문을 빠르게 이해하고 추가 비용 없이 가장 효과적으로 해결하는 데 도움이 되기를 바랍니다.

이 기사를 작성하는 주요 목적은 아직 1C에 대한 경험을 얻지 못한 관리자(및 프로그래머)에게 명백한 뉘앙스를 반복하지 않는 것입니다.

두 번째 목표는 나에게 부족한 점이 있으면 Infostart가 가장 빠르게 이를 지적해 주는 것입니다.

V. Gilev의 테스트는 이미 일종의 "사실상" 표준이 되었습니다. 그의 웹 사이트의 저자는 매우 명확한 권장 사항을 제시했지만, 나는 단지 몇 가지 결과를 제시하고 가장 가능성이 높은 오류에 대해 언급하겠습니다. 당연히 귀하의 장비에 대한 테스트 결과가 다를 수 있습니다. 이것은 단지 무엇이 되어야 하고 무엇을 위해 노력할 수 있는지에 대한 지침일 뿐입니다. 변경은 단계별로 이루어져야 하며, 각 단계가 끝나면 어떤 결과가 나오는지 즉시 확인하고 싶습니다.

Infostart에도 비슷한 기사가 있습니다. 관련 섹션에 해당 기사에 대한 링크를 넣겠습니다. 누락된 내용이 있으면 댓글로 제안해 주시면 추가하겠습니다. 따라서 1C가 느리다고 가정해 보겠습니다. 문제를 진단하는 방법과 관리자 또는 프로그래머의 책임을 이해하는 방법은 무엇입니까?

초기 데이터:

테스트된 컴퓨터, 기본 기니피그: HP DL180G6, 2*Xeon 5650, 32Gb, Intel 362i, Win 2008 r2가 장착되어 있습니다. 비교를 위해 Core i3-2100은 단일 스레드 테스트에서 비슷한 결과를 보여줍니다. 내가 의도적으로 선택한 장비는 최신 장비가 아니었고 최신 장비를 사용하면 결과가 눈에 띄게 좋아졌습니다.

별도의 1C 및 SQL 서버를 테스트하기 위해 SQL 서버: IBM System 3650 x4, 2*Xeon E5-2630, 32Gb, Intel 350, Win 2008 r2.

10Gbit 네트워크를 테스트하기 위해 Intel 520-DA2 어댑터가 사용되었습니다.

파일 버전. (데이터베이스는 서버의 공유 폴더에 있고 클라이언트는 네트워크, CIFS/SMB 프로토콜을 통해 연결됩니다.) 단계별 알고리즘:

0. Gilev의 테스트 데이터베이스를 기본 데이터베이스와 동일한 폴더의 파일 서버에 추가합니다. 클라이언트 컴퓨터에서 연결하고 테스트를 실행합니다. 우리는 그 결과를 기억합니다.

10년 전의 오래된 컴퓨터(775 소켓의 펜티엄)에서도 ) 1C:Enterprise 바로가기를 클릭한 후 데이터베이스 창이 나타날 때까지의 시간은 1분 미만이 소요됩니다. ( 셀러론 = 느림).

펜티엄보다 성능이 떨어지는 컴퓨터를 갖고 있다면 775 소켓 1GB RAM을 사용하는 경우 공감하며 파일 버전에서 1C 8.2에서 편안한 작업을 수행하기 어려울 것입니다. 업그레이드(적기) 또는 터미널(또는 씬 클라이언트 및 관리되는 양식의 경우 웹) 서버로 전환하는 것을 고려해보세요.

컴퓨터가 더 나쁘지 않으면 관리자를 쫓아 낼 수 있습니다. 최소한 네트워크, 바이러스 백신 및 HASP 보호 드라이버의 작동을 확인하십시오.

이 단계에서 Gilev의 테스트에서 30개 이상의 "앵무새"가 표시되었지만 1C 작업 기반이 여전히 느리게 작동하는 경우 질문은 프로그래머에게 전달되어야 합니다.

1. 클라이언트 컴퓨터가 얼마나 "압축"할 수 있는지에 대한 지침으로 네트워크 없이 이 컴퓨터만 작동하는지 확인합니다. 테스트 데이터베이스를 로컬 컴퓨터(매우 빠른 디스크)에 설치합니다. 클라이언트 컴퓨터에 일반 SSD가 없으면 램디스크가 생성됩니다. 현재로서는 가장 간단하고 무료인 것은 Ramdisk enterprise입니다.

버전 8.2를 테스트하려면 256MB 램디스크이면 충분합니다! 가장 중요한. 컴퓨터를 재부팅한 후 램디스크가 실행 중이면 100-200MB의 여유 공간이 있어야 합니다. 따라서 램디스크가 없으면 정상적인 작동을 위해서는 300-400MB의 여유 메모리가 있어야 합니다.

버전 8.3을 테스트하려면 256MB 램디스크이면 충분하지만 여유 RAM이 더 필요합니다.

테스트할 때 프로세서 로드를 살펴봐야 합니다. 이상적인 경우(램디스크)에 가까운 경우 로컬 파일 1c는 실행 시 프로세서 코어 1개를 로드합니다. 따라서 테스트 중에 프로세서 코어가 완전히 로드되지 않은 경우 약점을 찾으십시오. 약간 감정적이지만 일반적으로 정확하며 프로세서가 1C 작동에 미치는 영향이 설명됩니다. 참고로, 고주파수를 사용하는 최신 Core i3에서도 70~80이라는 숫자는 상당히 현실적입니다.

이 단계에서 가장 일반적인 오류입니다.

a) 바이러스 백신이 잘못 구성되었습니다. 바이러스 백신이 많고 각각의 설정이 다릅니다. 적절한 구성을 사용하면 웹이나 Kaspersky 1C가 방해하지 않는다고만 말씀드리겠습니다. 기본 설정에서는 약 3~5마리(10~15%)의 앵무새를 제거할 수 있습니다.

b) 성능 모드. 어떤 이유에서인지 이에 주목하는 사람은 거의 없지만 그 효과는 가장 중요합니다. 속도가 필요하다면 클라이언트와 서버 컴퓨터 모두에서 이 작업을 수행해야 합니다. ( 좋은 설명길레프의 집에서. 유일한 주의 사항은 일부 마더보드에서는 Intel SpeedStep을 끄면 TurboBoost를 켤 수 없다는 것입니다.

간단히 말해서 1C가 실행되는 동안 다른 장치(디스크, 네트워크 등)의 응답을 기다리는 시간이 많이 있습니다. 응답을 기다리는 동안 성능 모드가 활성화되면 프로세서는 주파수를 낮춥니다. 응답은 장치에서 나오며 1C(프로세서)는 작동해야 하지만 첫 번째 클록 사이클은 주파수가 감소한 다음 주파수가 증가하고 1C는 다시 장치의 응답을 기다립니다. 그리고 초당 수백 번.

다음 두 위치에서 성능 모드를 활성화할 수 있습니다(바람직하게는).

BIOS를 통해. 모드 C1, C1E, Intel C-state(C2, C3, C4)를 비활성화합니다. 다른 바이오스에서는 다르게 호출되지만 의미는 동일합니다. 검색하는데 시간이 오래 걸리고 재부팅도 필요하지만 한 번 하면 잊어버릴 수 있습니다. BIOS에서 모든 작업을 올바르게 수행하면 속도가 향상됩니다. 일부 마더보드에서는 Windows 성능 모드가 중요한 역할을 하지 않도록 BIOS 설정을 구성할 수 있습니다. (Gilev의 BIOS 설정 예) 이러한 설정은 주로 서버 프로세서 또는 "고급" BIOS와 관련이 있습니다. 이를 찾지 못했고 Xeon이 없어도 괜찮습니다.

제어판 - 전원 공급 장치 - 고성능. 마이너스 - 컴퓨터를 오랫동안 서비스하지 않으면 팬 소음이 커지고 발열이 심해지며 더 많은 에너지를 소비하게 됩니다. 성과보수입니다.

모드가 활성화되었는지 확인하는 방법. 작업 관리자 - 성능 - 리소스 모니터 - CPU를 실행하세요. 프로세서가 아무것도 사용하지 않을 때까지 기다립니다.

이는 기본 설정입니다.

BIOS C 상태 포함됨,

균형 잡힌 전력 소비 모드

BIOS C 상태 포함됨, 고성능 모드

Pentium과 Core의 경우 여기서 멈출 수 있습니다.

여전히 Xeon에서 약간의 "앵무새"를 짜낼 수 있습니다.

BIOS C 상태 껐다, 고성능 모드.

터보 부스트를 사용하지 않으면 다음과 같습니다.

성능에 맞게 조정된 서버

그리고 이제 숫자입니다. 상기시켜 드리겠습니다: Intel Xeon 5650, 램디스크. 첫 번째 경우 테스트에서는 23.26, 마지막 경우에는 49.5를 보여줍니다. 그 차이는 거의 두 배에 달합니다. 숫자는 다를 수 있지만 Intel Core의 비율은 기본적으로 동일하게 유지됩니다.

관리자 여러분, 원하는 만큼 1C를 비판할 수 있지만 최종 사용자에게 속도가 필요하다면 고성능 모드를 활성화해야 합니다.

c) 터보 부스트. 먼저, 예를 들어 프로세서가 이 기능을 지원하는지 이해해야 합니다. 지원된다면 여전히 합법적으로 일부 성능을 얻을 수 있습니다. (저는 주파수 오버클러킹, 특히 서버 문제를 다루고 싶지 않습니다. 위험과 위험을 감수하고 수행하십시오. 그러나 버스 속도를 133에서 166으로 높이면 속도와 열 방출이 눈에 띄게 증가한다는 데 동의합니다.)

터보 부스트를 켜는 방법은 예를 들어 . 하지만! 1C에는 약간의 뉘앙스가 있습니다(가장 명확하지는 않음). 어려운 점은 C-state를 켤 때 터보 부스트 효과가 최대로 발생한다는 점이다. 그리고 우리는 다음과 같은 것을 얻습니다:

배율이 최대이고, 코어 속도가 아름답고, 성능이 높다는 점을 참고하세요. 하지만 결과적으로 1s는 어떻게 될까요?

	요인	코어 속도(주파수), GHz	CPU-Z 단일 스레드	Gilev 램디스크 테스트 파일 버전	Gilev 램디스크 테스트 클라이언트 서버
터보 부스트 미적용
C 상태 꺼짐, 터보 부스트				53.19	40,32
C 상태 켜짐, 터보 부스트			1080	53,13	23,04

그러나 결국 CPU 성능 테스트에 따르면 배수가 23인 버전이 앞서는 것으로 나타났습니다. 파일 버전에서 Gilev의 테스트에 따르면 배수가 22와 23인 성능은 동일하지만 클라이언트-서버에서는 동일합니다. 버전 - 승수가 23인 버전은 끔찍합니다. (C 상태가 레벨 7로 설정되어 있어도 C 상태가 꺼진 경우보다 여전히 느립니다.) 따라서 두 가지 옵션을 모두 직접 확인하고 가장 적합한 옵션을 선택하는 것이 좋습니다. 어쨌든 49.5마리와 53마리의 앵무새 사이의 차이는 상당히 중요합니다. 특히 많은 노력을 기울이지 않으면 더욱 그렇습니다.

결론 - 터보 부스트를 켜야 합니다. BIOS에서 터보 부스트 항목을 활성화하는 것만으로는 충분하지 않으며 다른 설정도 살펴봐야 합니다(BIOS: QPI L0s, L1 - 비활성화, 요구 스크러빙 - 비활성화, Intel SpeedStep - 활성화, 터보 부스트 - 활성화 제어판 - 전원 옵션 - 고성능) . 그리고 비록 승수가 더 작더라도 나는 여전히 (파일 버전의 경우에도) c-state가 꺼진 옵션을 선택할 것입니다. 이런 내용이 나올 줄이야...

다소 논란의 여지가 있는 점은 메모리 빈도입니다. 예를 들어, 메모리 빈도는 매우 강한 영향을 미치는 것으로 나타났습니다. 내 테스트에서는 그러한 의존성이 밝혀지지 않았습니다. DDR 2/3/4를 비교하지 않고, 같은 라인 내에서 주파수를 변경한 결과를 보여드리겠습니다. 메모리는 동일하지만 BIOS에서는 더 낮은 주파수를 설정해야 합니다.

그리고 테스트 결과. 1C 8.2.19.83, 파일 버전 로컬 램디스크의 경우, 한 컴퓨터의 클라이언트-서버 1C 및 SQL용, 공유 메모리. 터보 부스트는 두 버전 모두에서 비활성화됩니다. 8.3은 비슷한 결과를 보여줍니다.

차이는 측정오차 이내입니다. 주파수 변경에 따라 다른 매개변수도 변경된다는 사실을 보여주기 위해 특별히 CPU-Z의 스크린샷을 꺼냈습니다. 동일한 CAS 대기 시간과 RAS-CAS 지연이 주파수 변경을 무력화합니다. 차이점은 메모리 모듈이 느린 것에서 빠른 것으로 물리적으로 변경되는 경우이지만, 거기에서도 숫자는 특별히 중요하지 않습니다.

2. 클라이언트 컴퓨터의 프로세서와 메모리를 정리한 후에는 매우 중요한 다음 장소인 네트워크로 이동합니다. 네트워크 튜닝에 관해 많은 양의 책이 저술되었으며 Infostart(및 기타)에 대한 기사가 있지만 여기서는 이 주제에 초점을 맞추지 않겠습니다. 1C 테스트를 시작하기 전에 두 컴퓨터 간의 iperf가 Gilev의 조언을 따른 전체 대역폭(1Gbit 카드의 경우 최소 850Mbit 또는 더 나은 경우 950-980)을 표시하는지 확인하십시오. 그런 다음 가장 간단한 작동 테스트는 이상하게도 네트워크를 통해 하나의 큰 파일(5-10GB)을 복사하는 것입니다. 1Gbit 네트워크에서 정상 작동을 나타내는 간접적인 신호는 평균 복사 속도가 100MB/초이고 양호한 작동 속도는 120MB/초입니다. 약점 (포함)이 프로세서 부하일 수 있다는 사실에 주목하고 싶습니다. 중소기업 Linux의 프로토콜은 병렬화 수준이 매우 낮으며 작동 중에 하나의 프로세서 코어를 쉽게 "먹고" 더 이상 소비하지 않을 수 있습니다.

그리고 더. 기본 설정을 사용하면 Windows 클라이언트는 Windows 서버(또는 Windows 워크스테이션)에서 가장 잘 작동하고 SMB/CIFS 프로토콜, Linux 클라이언트(debian, ubuntu는 다른 클라이언트를 보지 않음)에서 linux 및 NFS에서 더 잘 작동합니다( SMB에서도 작동하지만 NFS에서는 앵무새의 키가 더 큽니다. Windows Linux 서버를 NFS로 선형 복사하는 동안 하나의 스트림으로 더 빠르게 복사된다는 사실은 아무 의미가 없습니다. 1C용 데비안 튜닝은 별도 기사의 주제입니다. 아직 준비가 되지 않았습니다. 파일 버전에서는 동일한 장비에서 Win 버전보다 약간 더 나은 성능을 얻었다고 말할 수 있지만 postgres는 이상입니다. 사용자 50명 아직 모든 것이 매우 나쁩니다.

가장 중요한 , "불타는" 관리자는 알고 있지만 초보자는 고려하지 않습니다. 1c 데이터베이스에 대한 경로를 설정하는 방법에는 여러 가지가 있습니다. \\server\share를 수행할 수 있고, \\192.168.0.1\share를 수행할 수 있으며, z: \\192.168.0.1\share를 net use할 수 있습니다(어떤 경우에는 이 방법도 작동하지만 항상 그런 것은 아닙니다). Z 드라이브를 지정하십시오.이 모든 경로가 동일한 위치를 가리키는 것처럼 보이지만 1C의 경우 정상적인 성능을 매우 안정적으로 제공하는 방법은 단 하나뿐입니다. 따라서 올바르게 수행해야 할 작업은 다음과 같습니다.

명령줄(또는 정책 또는 귀하에게 편리한 모든 것)에서 DriveLetter: \\server\share를 사용하십시오. 예: 순 사용 m: \\서버\베이스. 나는 특히 IP 주소가 아닌 것을 강조합니다. 이름섬기는 사람. 서버 이름이 표시되지 않으면 서버의 DNS에 추가하거나 호스트 파일에 로컬로 추가하세요. 단, 주소는 반드시 이름으로 되어 있어야 합니다. 따라서 데이터베이스로 가는 도중에 이 디스크에 액세스합니다(그림 참조).

이제 이것이 왜 조언인지 숫자로 보여 드리겠습니다. 초기 데이터: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 카드 OS Win 2008 R2, Win 7, Debian 8. 최신 드라이버, 업데이트 적용. 테스트하기 전에 Iperf가 전체 대역폭을 제공하는지 확인했습니다(10Gbit 카드를 제외하고 7.2Gbit만 짜낼 수 있었습니다. 테스트 서버가 아직 제대로 구성되지 않은 이유는 나중에 알아보겠습니다). 디스크는 다르지만 SSD(테스트를 위해 특별히 단일 디스크를 삽입했는데 다른 디스크는 로드되지 않음) 또는 SSD의 RAID가 있는 모든 곳입니다. 100Mbit의 속도는 Intel 362 어댑터의 설정을 제한하여 얻은 것입니다. 1Gbit 구리 Intel 350과 1Gbit 광학 Intel X520-DA2(어댑터 속도를 제한하여 얻음) 사이에는 차이가 없었습니다. 최대 성능, 터보 부스트가 꺼집니다(결과 비교를 위해 좋은 결과에 대한 터보 부스트가 10% 미만으로 추가되고, 나쁜 결과에 대해서는 전혀 효과가 없을 수 있습니다). 버전 1C 8.2.19.86, 8.3.6.2076. 나는 모든 숫자를 제공하지는 않지만 가장 흥미로운 숫자만 제공하므로 비교할 것이 있습니다.

	2008년 승리 - 2008년 승리 IP 주소로 연락	2008년 승리 - 2008년 승리 이름으로 부르기	2008년 승리 - 2008년 승리 IP 주소로 연락하기	2008년 승리 - 2008년 승리 이름으로 부르기	승리 2008 - 승리 7 이름으로 부르기	승리 2008 - 데비안 이름으로 부르기	2008년 승리 - 2008년 승리 IP 주소로 연락하기	2008년 승리 - 2008년 승리 이름으로 부르기
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1C 8.2	11,29	26,18	15,29	43,10	40,65	36,76	15,11	44,10
8.2.19.83	12,15	25,77	15,15	43,10			14,97	42,74
	6,13	34,25	14,98	43,10	39,37	37,59	15,53	42,74
1C 8.3	6,61	33,33	15,58	43,86	40,00	37,88	16,23	42,74
8.3.6.2076		33,78	15,53	43,48	39,37	37,59		42,74

결론 (표와 개인적인 경험. 파일 버전에만 적용됩니다):

이 네트워크가 올바르게 구성되고 경로가 1C에 올바르게 입력되면 네트워크를 통해 매우 정상적인 작업 번호를 얻을 수 있습니다. 첫 번째 Core i3조차도 40개 이상의 앵무새를 쉽게 생산할 수 있는데, 이는 상당히 좋은 앵무새일 뿐만 아니라 실제 작업에서도 차이가 눈에 띕니다. 하지만! 여러(10명 이상) 사용자와 작업할 때 제한은 더 이상 네트워크가 아닙니다. 여기서는 1Gbit이면 충분하지만 다중 사용자 작업 중에는 차단됩니다(Gilev).

1C 8.3 플랫폼은 적절한 네트워크 구성 측면에서 몇 배 더 까다롭습니다. 기본 설정 - Gilev를 참조하세요. 하지만 모든 것이 영향을 받을 수 있다는 점을 명심하세요. 바이러스 백신 제거(단순히 끄는 것이 아니라), FCoE와 같은 프로토콜 제거, 드라이버를 이전 Microsoft 인증 버전(특히 ASUS 및 DLC와 같은 저렴한 카드의 경우)으로 변경, 두 번째 네트워크 카드 제거에서 가속화되는 것을 보았습니다. 서버에서. 다양한 옵션이 있으므로 네트워크를 신중하게 설정하세요. 플랫폼 8.2가 허용 가능한 숫자를 제공하고 8.3이 2배 이상 적은 상황이 있을 수 있습니다. 플랫폼 버전 8.3으로 플레이해 보면 때로는 매우 큰 효과를 얻을 수 있습니다.

1C 8.3.6.2076(나중에 아직 정확한 버전을 찾지 못했을 수도 있음)은 8.3.7.2008보다 네트워크를 통해 구성하기가 더 쉽습니다. 2008년 7월 8일부터 (비교할 만한 앵무새의 경우) 네트워크를 통해 몇 번만 정상적인 작동을 달성할 수 있었지만 보다 일반적인 경우에는 반복할 수 없었습니다. 잘 이해는 안됐지만 프로세스 익스플로러의 풋랩으로 판단하면 8.3.6만큼 녹음이 좋지는 않습니다.

100Mbit 네트워크에서 작업할 때 로드 일정이 적다는 사실에도 불구하고(네트워크가 무료라고 말할 수 있음) 작동 속도는 여전히 1Gbit보다 훨씬 낮습니다. 그 이유는 네트워크 지연 때문입니다.

1C 8.2의 다른 모든 사항(잘 작동하는 네트워크)이 동일하면 Intel-Realtek 연결은 Intel-Intel보다 10% 느립니다. 그러나 realtek-realtek은 일반적으로 갑자기 급격히 가라앉을 수 있습니다. 그러므로 돈이 있으면 인텔 네트워크 카드를 곳곳에 두는 것이 좋고, 돈이 없으면 서버(CO)에만 인텔을 설치하는 것이 좋습니다. 그리고 Intel 네트워크 카드 조정에 대한 지침이 몇 배나 더 많습니다.

기본 바이러스 백신 설정(예: drweb 버전 10 사용)은 앵무새의 약 8-10%를 차지합니다. 필요한 대로 구성하면(안전하지는 않지만 1cv8 프로세스가 모든 작업을 수행하도록 허용) 속도는 바이러스 백신이 없는 것과 동일합니다.

Linux 전문가를 읽지 마십시오. Samba가 포함된 서버는 훌륭하고 무료이지만 서버에 Win XP 또는 Win7(또는 더 나은 서버 OS)을 설치하면 1c의 파일 버전이 더 빠르게 작동합니다. 예, 삼바와 프로토콜 스택, 네트워크 설정 등 훨씬 더 많은 것들이 데비안/우분투에서 잘 조정될 수 있지만 이것은 전문가에게 권장됩니다. 기본 설정으로 Linux를 설치한 다음 느리다고 말하는 것은 의미가 없습니다.

fio를 사용하여 net use로 연결된 디스크의 작동을 확인하는 것은 꽤 좋은 생각입니다. 적어도 이것이 1C 플랫폼에 문제인지, 아니면 네트워크/디스크에 문제가 있는지는 분명할 것입니다.

단일 사용자 버전의 경우 1Gbit와 10Gbit의 차이가 눈에 띄는 테스트(또는 상황)가 생각나지 않습니다. 파일 버전의 10Gbit가 더 나은 결과를 제공한 유일한 방법은 iSCSI를 통해 디스크를 연결하는 것입니다. 그러나 이는 별도의 기사에 대한 주제입니다. 그래도 파일 버전의 경우 1Gbit 카드이면 충분하다고 생각합니다.

100Mbit 네트워크에서 8.3이 8.2보다 눈에 띄게 빠르게 작동하는 이유를 이해할 수 없지만 사실이었습니다. 다른 모든 장비, 다른 모든 설정은 완전히 동일합니다. 한 경우에는 8.2가 테스트되고 다른 경우에는 8.3이 테스트됩니다.

조정되지 않은 NFS win-win 또는 win-lin은 6개의 앵무새를 제공하지만 테이블에 포함시키지 않았습니다. 튜닝 후 25를 얻었으나 불안정했습니다(측정값 차이가 2단위 이상이었습니다). Windows 및 NFS 프로토콜 사용에 대한 권장 사항은 아직 제공할 수 없습니다.

모든 설정과 점검을 마친 후 클라이언트 컴퓨터에서 테스트를 다시 실행하고 향상된 결과에 기뻐합니다(작동하는 경우). 결과가 개선되었다면 앵무새가 30마리 이상(특히 40마리 이상)이고 동시에 작업하는 사용자가 10명 미만이며 작업 데이터베이스가 여전히 느린 경우입니다. 이는 거의 확실하게 프로그래머에게 문제가 있는 것입니다. 이미 파일 버전의 최고 성능에 도달했습니다).

터미널 서버. (데이터베이스는 서버에 있고 클라이언트는 네트워크, RDP 프로토콜을 통해 연결됩니다). 단계별 알고리즘:

0. Gilev의 테스트 데이터베이스를 기본 데이터베이스와 동일한 폴더에 있는 서버에 추가합니다. 동일한 서버에서 연결하여 테스트를 실행합니다. 우리는 그 결과를 기억합니다.

1. 파일버전과 동일하게 작품을 구성합니다. 터미널 서버의 경우 일반적으로 프로세서가 주요 역할을 담당합니다(메모리 부족이나 엄청난 양의 불필요한 소프트웨어 등 눈에 띄는 약점은 없는 것으로 가정).

2. 터미널 서버의 경우 네트워크 카드 설정은 1c의 작동에 사실상 영향을 미치지 않습니다. "특별한" 편안함을 보장하기 위해 서버에서 50마리 이상의 앵무새를 생산하는 경우 사용자의 편안함, 더 빠른 응답 및 스크롤을 위해 새로운 버전의 RDP 프로토콜을 사용할 수 있습니다.

3. 많은 수의 사용자가 적극적으로 작업하고 있다면(여기서 이미 30명을 하나의 데이터베이스에 연결하려고 시도할 수 있다면) SSD 드라이브를 설치하는 것이 매우 좋습니다. 어떤 이유로 디스크가 1C의 작동에 특별히 영향을 미치지 않는 것으로 여겨지지만 모든 테스트는 쓰기가 가능한 컨트롤러 캐시로 수행되는데 이는 올바르지 않습니다. 테스트 기반은 작고 캐시에 아주 잘 맞으므로 숫자가 높습니다. 실제(대규모) 데이터베이스에서는 모든 것이 완전히 다르기 때문에 테스트를 위해 캐시가 비활성화됩니다.

예를 들어 다양한 디스크 옵션으로 Gilev 테스트의 작동을 확인했습니다. 나는 경향을 보여주기 위해 가까이에 있는 디스크를 설치했습니다. 8.3.6.2076과 8.3.7.2008의 차이는 작습니다(Ramdisk Turbo Boost 버전 8.3.6에서는 56.18을 생성하고 8.3.7.2008에서는 55.56을 생성하며 다른 테스트에서는 차이가 훨씬 작습니다). 전력 소비 - 최대 성능, 터보 부스트 비활성화(달리 명시되지 않는 한).

	RAID 10 4x SATA 7200 ATA ST31500341AS	RAID 10 4x SAS 10k	RAID 10 4x SAS 15k	단일 SSD	램디스크		캐시 활성화됨 RAID 컨트롤러
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1C 8.2	21,65	28,57	32,05	48,54	49,02	53,19
8.2.19.83	21,65	28,41	31,45	48,54	49,50	53,19
	33,33	42,74	45,05	51,55	52,08	55,56	51,55
1C 8.3	33,46	42,02	45,05	51,02	52,08	54,95
8.3.7.2008	35,46	43,01	44,64	51,55	52,08	56,18

활성화된 RAID 컨트롤러 캐시는 디스크 간의 모든 차이점을 제거합니다. 숫자는 sat와 cas 모두 동일합니다. 소량의 데이터에 대해 테스트하는 것은 쓸모가 없으며 어떤 종류의 지표도 아닙니다.

플랫폼 8.2의 경우 SATA와 SSD 옵션 간의 성능 차이가 두 배 이상입니다. 이것은 오타가 아닙니다. SATA 드라이브 테스트 중에 성능 모니터를 보면. 그러면 "활성 디스크 작동 시간(%)" 80-95를 명확하게 볼 수 있습니다. 예, 기록을 위해 디스크 자체의 캐시를 활성화하면 RAID 컨트롤러의 캐시를 활성화하면 속도가 35로 증가합니다(현재 테스트 중인 디스크에 관계없이 최대 49). 그러나 이는 합성 캐시 앵무새이므로 실제 작업에서 대규모 데이터베이스를 사용하는 경우 쓰기 캐시 적중률이 100%일 수 없습니다.

저렴한 SSD(Agility 3에서 테스트)의 속도도 파일 버전을 실행하기에 충분합니다. 녹음 리소스는 또 다른 문제이므로 각각을 살펴봐야 합니다. 특정한 경우, Intel 3700이 훨씬 더 높을 것이라는 것은 분명하지만 가격은 그에 상응합니다. 그리고 예, SSD 디스크를 테스트할 때 이 디스크의 캐시도 더 많이 테스트하지만 실제 결과는 이보다 적다는 것을 이해합니다.

내 관점에서 가장 정확한 솔루션은 파일 데이터베이스(또는 여러 파일 데이터베이스)에 대한 미러링 RAID에 2개의 SSD 디스크를 할당하고 거기에 다른 것을 배치하지 않는 것입니다. 예, 미러를 사용하면 SSD가 똑같이 마모되며 이는 마이너스이지만 적어도 컨트롤러 전자 장치는 어떻게든 오류로부터 보호됩니다.

파일 버전에 대한 SSD 드라이브의 주요 장점은 각 사용자가 여러 명인 데이터베이스가 많을 때 나타납니다. 데이터베이스가 1~2개 있고 사용자가 10명 정도인 경우 SAS 디스크이면 충분합니다. (그러나 어떤 경우에도 적어도 perfmon을 통해 이러한 디스크를 로드하는 것을 살펴보십시오.)

터미널 서버의 주요 장점은 클라이언트가 매우 약할 수 있으며 네트워크 설정이 터미널 서버에 미치는 영향(K.O.)이 훨씬 적다는 것입니다.

결론: 터미널 서버(작업 데이터베이스가 있는 동일한 디스크에서)에서 작업 데이터베이스 속도가 느려지는 순간에 Gilev 테스트를 실행하고 Gilev 테스트에서 좋은 결과(30 이상)가 표시되면 기본 작업 데이터베이스의 느린 작동은 아마도 프로그래머의 책임일 것입니다.

Gilev의 테스트에 작은 숫자가 표시되고 클럭이 높은 프로세서와 빠른 디스크가 있는 경우 관리자는 최소한 성능 테스트를 수행하여 모든 결과를 어딘가에 기록하고 관찰하고 결론을 도출해야 합니다. 확실한 조언은 없을 것입니다.

클라이언트-서버 옵션.

테스트는 8.2에서만 수행되었습니다. 8.3에서는 모든 것이 버전에 따라 매우 심각하게 달라집니다.

테스트를 위해 주요 추세를 보여주기 위해 서로 다른 서버 옵션과 네트워크를 선택했습니다.

	SQL: 제온 E5-2630	SQL: 제온 E5-2630 파이버 채널 - SSD	SQL: 제온 E5-2630 파이버 채널 - SAS	SQL: 제온 E5-2630 로컬 SSD	SQL: 제온 E5-2630 파이버 채널 - SSD	SQL: 제온 E5-2630 로컬 SSD	1C: 제온 5650 =	1C: 제온 5650 = 공유 메모리	1C: 제온 5650 =	1C: 제온 5650 =	1C: 제온 5650 =
	16,78	18,23	16,84	28,57	27,78	32,05	34,72	36,50	23,26	40,65	39.37
1C 8.2	17,12	17,06	14,53	29,41	28,41	31,45	34,97	36,23	23,81	40,32	39.06
	16,72	16,89	13,44	29,76	28,57	32,05	34,97	36,23	23,26	40,32	39.06

흥미로운 옵션을 모두 고려한 것 같습니다. 관심있는 다른 사항이 있으면 댓글에 적어 주시면 시도해 보겠습니다.

스토리지 시스템의 캐시 크기가 더 크더라도 스토리지 시스템의 SAS는 로컬 SSD보다 느립니다. 로컬 및 스토리지 시스템의 SSD는 Gilev의 테스트에서 비슷한 속도로 작동합니다. MCC에서 1C 로드 테스트를 제외하고는 표준 멀티 스레드 테스트(녹음뿐만 아니라 모든 장비)를 모릅니다.

1C 서버를 5520에서 5650으로 변경하면 성능이 거의 두 배 향상되었습니다. 예, 서버 구성이 완전히 일치하지는 않지만 추세를 보여줍니다(놀랍지 않습니다).

SQL 서버의 빈도를 높이면 확실히 효과가 있지만 1C 서버와 동일하지는 않습니다. MS SQL 서버는 멀티 코어 및 여유 메모리를 사용하는 데 탁월합니다.

1C와 SQL 간의 네트워크를 1Gbit에서 10Gbit로 변경하면 약 10%의 앵무새가 제공됩니다. 나는 더 많은 것을 기대했다.

공유 메모리를 활성화하면 설명된 대로 15%는 아니지만 여전히 효과가 있습니다. 꼭 해보세요. 다행스럽게도 빠르고 쉽습니다. 설치 중에 누군가 SQL 서버에 명명된 인스턴스를 제공한 경우 1C가 작동하려면 서버 이름을 FQDN(tcp/ip는 작동함)이 아닌 localhost나 ServerName을 통해서가 아니라 ServerName\InstanceName을 통해 지정해야 합니다. zz-테스트\zztest. (그렇지 않으면 DBMS 오류가 발생합니다. Microsoft SQL Server Native Client 10.0: Shared Memory Provider: SQL Server 2000과의 연결을 설정하는 데 사용된 공유 메모리 라이브러리를 찾을 수 없습니다. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr : SQLSTATE=08001, 상태=1, 심각도=10, 기본=126, 줄=0).

사용자가 100명 미만인 경우 두 개의 별도 서버로 분할하는 유일한 방법은 32GB RAM만 지원하는 Win 2008 Std(및 이전 버전) 라이선스입니다. 다른 모든 경우에는 1C와 SQL을 하나의 서버에 설치하고 더 많은(최소 64GB) 메모리를 제공해야 합니다. MS SQL에 24-28GB 미만의 RAM을 제공하는 것은 부당한 탐욕입니다. 메모리가 충분하고 모든 것이 잘 작동한다고 생각한다면 1C의 파일 버전이면 충분할 것입니다.

가상 머신에서 1C와 SQL의 조합이 얼마나 더 나쁘게 작동하는지는 별도의 기사 주제입니다(힌트 - 눈에 띄게 더 나쁨). Hyper-V에서도 모든 것이 명확하지 않습니다.

균형 잡힌 성능 모드가 좋지 않습니다. 결과는 파일 버전과 상당히 일치합니다.

많은 소스에서는 디버깅 모드(ragent.exe -debug)가 성능을 크게 저하시킨다고 말합니다. 글쎄요, 그렇습니다. 하지만 2~3%가 유의미한 효과라고는 할 수 없습니다.