질문이 생깁니다 : 1C 용 DBMS는 파일 또는 SQL 중 무엇을 선택합니까?

파일 기반이 무엇인지, 서버측 SQL 클라이언트가 무엇인지 알아보도록 하겠습니다.

DBMS는 데이터베이스 관리 시스템입니다. 1C Enterprise 플랫폼은 다음 DBMS 옵션을 지원합니다.

• 파일(내장 1C)
• MS SQL 서버
• 신탁
• IBM DB2
• PostgreSQL

파일 버전은 1C Enterprise를 구현하는 가장 쉬운 방법입니다. 추가 소프트웨어를 설치할 필요가 없습니다. 파일 버전은 웹 어디에서나 액세스할 수 있는 공용 데이터베이스 파일입니다.

267개의 1C 비디오 강의를 무료로 받으세요:

파일 옵션의 장점:

• 설정하기 쉽습니다.
• 추가 소프트웨어가 필요하지 않습니다.
• 싸고 쾌활합니다.

결점:

• 보안이 없습니다. 시스템의 모든 사용자는 데이터베이스 파일을 복사할 수 있습니다.
• 시스템의 낮은 확장성 - 어떤 경우에는 시스템이 이미 5-7명의 사용자와 함께 느리게 작동하기 시작합니다. 이는 트랜잭션 격리 수준이 높아졌기 때문입니다.
• 일부 프로그램 기능은 파일 모드에서 작동하지 않습니다(예: 예약된 작업).
• 크기 제한(최대 4-12GB).

1C용 클라이언트-서버 DBMS

이 버전의 아키텍처 장치는 향상된 내결함성과 보안에 적합합니다. 매우 많은 수의 사용자(최대 5000명 이상)가 클라이언트-서버 시스템에서 동시에 작업할 수 있습니다.

사용의 장점:

• 향상된 내결함성.
• 동시에 많은 수의 사용자와 작업할 수 있습니다.
• 데이터베이스의 크기는 아무 것도 제한하지 않습니다.
• 무료 DBMS(PostgreSQL)가 있습니다.

• 모든 DBMS가 무료는 아니며 가장 좋은 것(MS SQL Server)은 상당한 비용이 듭니다.
• SQL 서버 관리가 필요합니다.

파일 데이터베이스에서 SQL로 마이그레이션하기 위한 지침

1C 8.3(8.2) 기반을 파일에서 클라이언트-서버 모드로 전송하기로 결정한 경우 다음 지침을 따르십시오.

1. SQL에서 새로운 1C 데이터베이스를 생성하십시오.
2. 파일 베이스에서 *.dt 파일을 업로드합니다(Configurator - Administration - Upload infobase).
3. 결과 파일을 새 데이터베이스에 업로드합니다(Configurator - Administration - Infobase upload).

결론

사진: Alena Tulyakova, IA Clerk.Ru

이 기사는 초보 1C 관리자가 저지르는 주요 실수를 설명하고 Gilev 테스트의 예를 사용하여 이를 해결하는 방법을 보여줍니다.

이 기사를 작성하는 주요 목적은 아직 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년 전 구형 컴퓨터(Pentium on 775 소켓)의 경우에도 1C:Enterprise 바로 가기를 클릭하여 데이터베이스 창을 표시하는 데 걸리는 시간은 1분 미만이어야 합니다. (셀러론 = 느린 작업).

컴퓨터가 1GB RAM의 775 소켓 펜티엄보다 나쁘다면 공감하며 파일 버전에서 1C 8.2에서 편안한 작업을 수행하기 어려울 것입니다. 업그레이드(오래 기한이 지난) 또는 터미널(또는 씬 클라이언트 및 관리 양식의 경우 웹) 서버로 전환하는 것을 고려하십시오.

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

이 단계에서 Gilev의 테스트에서 30개의 "앵무새" 이상이 표시되었지만 1C 작업 기반이 여전히 느리게 작동한다면 질문은 이미 프로그래머에게 있습니다.

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

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

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

테스트할 때 프로세서 부하를 확인해야 합니다. 이상(ramdisk)에 가까운 경우 로컬 파일 1c는 동작 중에 프로세서 코어 1개를 로드합니다. 따라서 테스트 중에 프로세서 코어가 완전히 로드되지 않은 경우 약점을 찾으십시오. 약간 감정적이지만 일반적으로 정확하며 1C 작동에 대한 프로세서의 영향이 설명됩니다. 참고로 고주파수 최신 Core i3에서도 70-80이라는 숫자는 매우 현실적입니다.

이 단계에서 가장 흔한 실수.

• 잘못 구성된 바이러스 백신. 많은 바이러스 백신이 있으며 각각의 설정이 다릅니다. 적절한 구성을 사용하면 웹이나 Kaspersky 1C가 방해하지 않는다고 말할 수 있습니다. "기본" 설정으로 약 3-5마리의 앵무새(10-15%)를 제거할 수 있습니다.
• 성능 모드. 어떤 이유로 이것에주의를 기울이는 사람은 거의 없으며 그 효과가 가장 중요합니다. 속도가 필요한 경우 클라이언트와 서버 컴퓨터 모두에서 속도를 높여야 합니다. (Gilev는 좋은 설명을 가지고 있습니다. 유일한 주의 사항은 일부 마더보드에서 Intel SpeedStep이 꺼져 있으면 TurboBoost를 켤 수 없다는 것입니다.)

다음 두 위치에서 성능 모드를 활성화할 수 있습니다.

• BIOS를 통해. C1, C1E, Intel C-state(C2, C3, C4) 모드를 비활성화합니다. 다른 바이오스에서는 다르게 호출되지만 의미는 동일합니다. 오랫동안 검색하면 재부팅이 필요하지만 한 번하면 잊을 수 있습니다. BIOS에서 모든 것이 올바르게 완료되면 속도가 추가됩니다. 일부 마더보드에서는 Windows 성능 모드가 역할을 하지 않도록 BIOS 설정을 설정할 수 있습니다. (Gilev의 BIOS 설정 예). 이러한 설정은 주로 서버 프로세서 또는 "고급" BIOS와 관련이 있습니다. 시스템에서 찾을 수 없고 Xeon이 없는 경우 괜찮습니다.

• 제어판 - 전원 - 고성능. 빼기-컴퓨터를 오랫동안 서비스하지 않으면 팬과 함께 더 강하게 윙윙 거리고 더 많이 가열되고 더 많은 에너지를 소비합니다. 이것은 성능의 가격입니다.

이것이 기본 설정입니다. BIOS C-상태 활성화, 균형 잡힌 전력 모드
BIOS C-state 활성화, 고성능 모드 Pentium 및 Core의 경우 여기서 멈출 수 있습니다. 여전히 Xeon에서 일부 "앵무새"를 짜낼 수 있습니다.
BIOS에서 C 상태는 꺼져 있고 고성능 모드입니다. 터보 부스트를 사용하지 않는 경우 - 다음과 같이 표시됩니다. 성능을 위해 조정된 서버

그리고 이제 숫자입니다. 상기시켜 드리겠습니다: Intel Xeon 5650, ramdisk. 첫 번째 경우 테스트는 23.26을 표시하고 후자는 49.5를 표시합니다. 그 차이는 거의 두 배입니다. 숫자는 다를 수 있지만 비율은 Intel Core에서 거의 동일하게 유지됩니다.

친애하는 관리자 여러분, 원하는 대로 1C를 꾸짖을 수 있지만 최종 사용자가 속도를 필요로 하는 경우 고성능 모드를 활성화해야 합니다.

c) 터보 부스트. 예를 들어 프로세서가 이 기능을 지원하는지 먼저 이해해야 합니다. 그렇다면 여전히 합법적으로 약간의 성능을 얻을 수 있습니다. (오버클러킹, 특히 서버 문제에 대해서는 언급하고 싶지 않습니다. 자신의 위험과 위험을 감수해야 합니다. 하지만 버스 속도를 133에서 166으로 높이면 속도와 열 발산이 모두 눈에 띄게 증가한다는 데 동의합니다.)

예를 들어 터보 부스트를 켜는 방법이 쓰여 있습니다. 하지만! 1C의 경우 약간의 뉘앙스가 있습니다(가장 명백하지는 않음). 어려움은 C-state를 켰을 때 터보 부스트의 최대 효과가 나타난다는 점이다. 그리고 다음과 같은 그림이 나옵니다.

승수는 최대이고 코어 속도는 가장 아름답고 성능은 높습니다. 그러나 1s의 결과는 어떻게 될까요?

그러나 결국 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, 파일 버전 로컬 ramdisk, 클라이언트-서버 1C 및 한 컴퓨터의 SQL, 공유 메모리. 두 옵션 모두에서 터보 부스트가 비활성화됩니다. 8.3은 비교 가능한 결과를 보여줍니다.

차이는 측정 오류 내에 있습니다. 특히 CPU-Z 스크린샷을 뽑아 다른 매개변수가 주파수 변경, 동일한 CAS 대기 시간 및 RAS에서 CAS 지연으로 변경되어 주파수 변경을 평준화하는 것을 보여줍니다. 차이점은 메모리 모듈이 물리적으로 더 느린 속도에서 더 빠른 속도로 변경될 때이지만 거기에서도 숫자는 그다지 중요하지 않습니다.

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

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

가장 중요한 것은 "번트"관리자가 알고 있지만 초보자는 고려하지 않는 것입니다. 1c 데이터베이스의 경로를 설정하는 방법에는 여러 가지가 있습니다. servershare, 192.168.0.1share, net use z: 192.168.0.1share(경우에 따라 이 방법도 작동하지만 항상 그런 것은 아님)을 만든 다음 드라이브 Z를 지정할 수 있습니다. 이 모든 경로가 가리키는 것 같습니다. 같은 장소에 같은 장소에 있지만 1C의 경우 상당히 안정적인 성능을 제공하는 방법은 하나뿐입니다. 따라서 올바르게 수행해야 할 사항은 다음과 같습니다.

명령줄(또는 정책 또는 귀하에게 적합한 모든 것)에서 DriveLetter: servershare를 net 사용하십시오. 예: net use m:serverbases. 특히 IP 주소가 아니라 서버 이름을 강조합니다. 서버가 이름으로 표시되지 않으면 서버의 dns에 추가하거나 호스트 파일에 로컬로 추가합니다. 그러나 항소는 이름으로 해야 합니다. 따라서 데이터베이스로 가는 도중에 이 디스크에 액세스하십시오(그림 참조).

이제 그러한 조언이 왜 필요한지 숫자로 보여드리겠습니다. 초기 데이터: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 카드 OS Win 2008 R2, Win 7, Debian 8. 최신 드라이버, 업데이트 적용. 테스트하기 전에 Iperf가 전체 대역폭을 제공하는지 확인했습니다. 디스크는 다르지만 모든 곳에 SSD(테스트를 위해 특별히 삽입된 단일 디스크, 다른 것은 로드되지 않음) 또는 SSD의 RAID가 있습니다. 100Mbit의 속도는 Intel 362 어댑터의 설정을 제한하여 얻은 것입니다. 최대 성능, 터보 부스트는 비활성화됩니다(결과 비교를 위해 터보 부스트는 좋은 결과에 대해 10% 미만을 추가하고 나쁜 결과에 대해서는 전혀 영향을 미치지 않을 수 있음). 버전 1C 8.2.19.86, 8.3.6.2076. 나는 모든 숫자를 제공하지는 않지만 비교할 것이 있도록 가장 흥미로운 숫자 만 제공합니다.

결론 (표 및 개인 경험에서. 파일 버전에만 적용됨):

• 네트워크를 통해이 네트워크가 정상적으로 구성되고 경로가 1C로 올바르게 작성된 경우 작업에 대한 정상적인 번호를 얻을 수 있습니다. 첫 번째 Core i3조차도 40 개 이상의 앵무새를 줄 수 있습니다. 이는 꽤 좋으며 앵무새 일뿐만 아니라 실제 작업에서도 그 차이가 눈에 띕니다. 하지만! 여러 사용자(10명 이상)와 함께 작업할 때의 제한은 더 이상 네트워크가 아닙니다. 여기에서는 여전히 1Gbit이면 충분하지만 다중 사용자 작업(Gilev) 중에는 차단됩니다.
• 플랫폼 1C 8.3은 유능한 네트워크 설정에 대해 몇 배 더 요구됩니다. 기본 설정 - Gilev를 참조하십시오. 그러나 모든 것이 영향을 미칠 수 있음을 명심하십시오. FCoE와 같은 프로토콜을 제거하고 드라이버를 이전 버전으로 변경하지만 Microsoft 인증 버전(특히 asus 및 longs와 같은 저렴한 카드의 경우)에서 바이러스 백신을 제거(단지 끄는 것이 아니라)한다는 사실에서 가속화를 보았습니다. 서버의 두 번째 네트워크 카드. 많은 옵션, 신중하게 네트워크를 구성하십시오. 플랫폼 8.2가 허용 가능한 숫자를 제공하고 8.3이 2배 이상 적은 상황이 있을 수 있습니다. 플랫폼 버전 8.3을 가지고 놀아보십시오. 때로는 매우 큰 효과를 얻을 수 있습니다.
• 1C 8.3.6.2076(어쩌면 나중에 정확한 버전을 아직 찾지 못했을 수도 있음)은 네트워크를 통해 여전히 8.3.7.2008보다 설정하기 쉽습니다. 2008년 8월 3일부터 정상적인 네트워크 작동(비슷한 앵무새에서)을 달성하기 위해 몇 번 밖에 나오지 않았으며 더 일반적인 경우에는 반복할 수 없었습니다. 나는 많이 이해하지 못했지만 Process Explorer의 족보로 판단하면 녹음이 8.3.6에서와 같은 방식으로 진행되지 않습니다.
• 100Mbps 네트워크에서 작업할 때 로드 일정이 적음에도 불구하고(네트워크가 무료라고 말할 수 있음) 작업 속도는 여전히 1Gbps보다 훨씬 낮습니다. 그 이유는 네트워크 대기 시간 때문입니다.
• 1C 8.2용 Ceteris paribus(잘 작동하는 네트워크), Intel-Realtek 연결은 Intel-Intel보다 10% 느립니다. 그러나 realtek-realtek은 일반적으로 갑작스럽게 급격한 침하를 줄 수 있습니다. 따라서 돈이 있으면 Intel 네트워크 카드를 어디에나 두는 것이 좋으며 돈이 없으면 Intel을 서버 (KO)에만 두십시오. 예, 인텔 네트워크 카드 튜닝에 대한 몇 배 더 많은 지침이 있습니다.
• 기본 바이러스 백신 설정(예: drweb 10 버전)은 앵무새의 약 8-10%를 제거합니다. 올바르게 구성하면(안전하지는 않지만 1cv8 프로세스가 모든 작업을 수행하도록 허용) 속도는 바이러스 백신이 없는 것과 동일합니다.
• Linux 전문가를 읽지 마십시오. 삼바가있는 서버는 훌륭하고 무료이지만 서버 (또는 더 나은 서버 OS)에 Win XP 또는 Win7을 넣으면 파일 버전 1c에서 더 빨리 작동합니다. 예, 삼바와 프로토콜 스택, 네트워크 설정 등이 데비안/우분투에서 잘 조정되지만 전문가에게 권장됩니다. 기본 설정으로 Linux를 설치한 다음 느리다고 말하는 것은 말이 되지 않습니다.
• fio 를 사용하여 net use를 통해 연결된 디스크를 테스트하는 것이 좋습니다. 적어도 이것이 1C 플랫폼의 문제인지 네트워크 / 디스크의 문제인지는 분명합니다.
• 단일 사용자 변형의 경우 1Gb와 10Gb의 차이가 보이는 테스트(또는 상황)를 생각할 수 없습니다. 파일 버전의 10Gbps가 더 나은 결과를 제공한 유일한 곳은 iSCSI를 통해 디스크를 연결하는 것이었지만 이것은 별도의 기사에 대한 주제입니다. 그래도 파일 버전은 1Gbit 카드면 충분하다고 생각합니다.
• 100Mbit 네트워크에서 8.3이 8.2보다 눈에 띄게 빠르게 작동하는 이유는 무엇입니까? 이해가 안되지만 사실이 발생했습니다. 다른 모든 장비, 다른 모든 설정은 정확히 동일하며 한 경우에는 8.2가 테스트되고 다른 경우에는 8.3이 테스트됩니다.
• 조정되지 않은 NFS win - win 또는 win-lin은 6마리의 앵무새를 제공하며 테이블에 포함하지 않았습니다. 튜닝 후 25를 받았지만 불안정합니다 (측정의 상승이 2 단위 이상입니다). 지금까지 Windows 및 NFS 프로토콜 사용에 대한 권장 사항을 제공할 수 없습니다.

터미널 서버. (기본은 서버에 있고 클라이언트는 네트워크, RDP 프로토콜에 연결됨). 단계별 알고리즘:

• 기본 데이터베이스와 동일한 폴더에 있는 서버에 Gilev 테스트 데이터베이스를 추가합니다. 동일한 서버에서 연결하고 테스트를 실행합니다. 우리는 그 결과를 기억합니다.
• 파일 버전과 같은 방식으로 프로세서를 설정합니다. 터미널 서버의 경우 일반적으로 프로세서가 주요 역할을 수행합니다(메모리 부족이나 불필요한 소프트웨어 양이 많은 것과 같은 명백한 약점은 없는 것으로 이해됨).
• 터미널 서버의 경우 네트워크 카드 설정은 1s의 작동에 거의 영향을 미치지 않습니다. "특별한" 편안함을 제공하기 위해 서버에서 50마리 이상의 앵무새를 제공하는 경우 사용자의 편안함, 빠른 응답 및 스크롤을 위해 새 버전의 RDP 프로토콜을 가지고 놀 수 있습니다.
• 많은 사용자의 활발한 작업으로 (그리고 여기에서 시도하면 이미 30 명을 하나의 기반에 연결하려고 시도 할 수 있음) SSD 드라이브를 설치하는 것이 매우 바람직합니다. 어떤 이유로 디스크가 1C의 작동에 특별히 영향을 미치지 않는다고 생각되지만 모든 테스트는 쓰기가 가능한 컨트롤러 캐시로 수행되며 이는 잘못된 것입니다. 테스트 기반은 작고 캐시에 적합하므로 숫자가 높습니다. 실제(대형) 데이터베이스에서는 모든 것이 완전히 다르기 때문에 테스트를 위해 캐시가 비활성화됩니다.

• RAID 컨트롤러의 포함된 캐시는 디스크 간의 모든 차이점을 제거하며 숫자는 sat 및 sas에서 동일합니다. 소량의 데이터에 대해 테스트하는 것은 쓸모가 없으며 지표가 아닙니다.
• 8.2 플랫폼의 경우 SATA와 SSD 옵션 간의 성능 차이는 두 배 이상입니다. 오타가 아닙니다. SATA 드라이브에서 테스트하는 동안 성능 모니터를 보는 경우. 그런 다음 명확하게 보이는 "활성 디스크 시간(%)" 80-95가 있습니다. 예, 디스크 자체의 쓰기 캐시를 활성화하면 RAID 컨트롤러 캐시를 활성화하면 최대 49까지 속도가 35로 증가합니다(현재 테스트 중인 디스크에 관계없이). 그러나 이들은 캐시의 합성 앵무새이며 대규모 데이터베이스를 사용한 실제 작업에서는 100% 쓰기 캐시 적중률이 없습니다.
• 저렴한 SSD(Agility 3에서 테스트)의 속도도 파일 버전이 작동하기에 충분합니다. 쓰기 리소스는 또 다른 문제입니다. 여기에서 각각의 특정 사례를 살펴봐야 합니다. Intel 3700이 훨씬 더 높을 것이 분명하지만 가격이 상응합니다. 그리고 예, SSD 드라이브를 테스트할 때 이 드라이브의 캐시도 더 많이 테스트하면 실제 결과가 적을 것임을 이해합니다.
• (내 관점에서) 가장 정확한 솔루션은 2개의 SSD 디스크를 파일 기반(또는 여러 파일 기반)에 대한 미러 RAID에 할당하고 거기에 다른 것을 넣지 않는 것입니다. 예, 거울을 사용하면 SSD가 같은 방식으로 마모되며 이것은 마이너스이지만 적어도 컨트롤러 전자 장치의 오류에 대해 어떻게 든 보장됩니다.
• 파일 버전용 SSD 디스크의 주요 이점은 데이터베이스가 많고 각각 사용자가 여러 명일 때 나타납니다. 1-2개의 베이스가 있고 10개의 지역에 사용자가 있는 경우 SAS 디스크로 충분합니다. (그러나 어쨌든 - 적어도 perfmon을 통해 이러한 디스크의 로딩을 살펴보십시오).
• 터미널 서버의 주요 이점은 매우 약한 클라이언트를 가질 수 있고 네트워크 설정이 터미널 서버에 훨씬 덜 영향을 미친다는 것입니다(다시 KO).

Gilev 테스트에서 작은 숫자가 표시되고 고주파 및 빠른 디스크가있는 프로세서가 모두있는 경우 여기에서 관리자는 최소한 perfmon을 수행하고 모든 결과를 어딘가에 기록하고 관찰하고 관찰하고 결론을 도출해야합니다. 결정적인 조언은 없을 것입니다.

클라이언트-서버 옵션.

테스트는 8.2, tk에서만 수행되었습니다. 8.3에서는 모든 것이 버전에 따라 크게 달라집니다.

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

나는 모든 흥미로운 옵션을 고려한 것 같습니다. 다른 것에 관심이 있다면 의견을 작성하십시오. 그렇게하려고 노력할 것입니다.

• 스토리지의 SAS는 스토리지의 캐시 크기가 크더라도 로컬 SSD보다 느립니다. Gilev 테스트를 위한 SSD와 로컬 및 스토리지 시스템은 비슷한 속도로 작동합니다. MCC에서 로드 1C를 제외하고는 표준 다중 스레드 테스트(기록뿐만 아니라 모든 장비)를 모릅니다.
• 1C 서버를 5520에서 5650으로 변경하면 성능이 거의 두 배로 향상되었습니다. 예, 서버 구성이 완전히 일치하지는 않지만 추세를 보여줍니다(놀라운 것은 아닙니다).
• 물론 SQL 서버의 빈도를 높이면 효과가 있지만 1C 서버와 같지는 않습니다. MS SQL Server는 멀티 코어 및 여유 메모리를 완벽하게 사용할 수 있습니다.
• 1C와 SQL 사이의 네트워크를 1Gbps에서 10Gbps로 변경하면 앵무새의 약 10%가 제공됩니다. 더 많은 것을 기대했습니다.
• 공유 메모리를 활성화하면 문서에 설명된 대로 15%는 아니지만 여전히 효과가 있습니다. 빠르고 쉽게 할 수 있습니다. 누군가가 설치 중에 SQL 서버에 명명된 인스턴스를 제공한 경우 1C가 작동하려면 서버 이름을 FQDN(tcp / ip가 작동함)이 아니라 localhost 또는 ServerName을 통해서가 아니라 ServerNameInstanceName을 통해 지정해야 합니다(예: zz- testzztest. (그렇지 않으면 다음 DBMS 오류가 발생합니다. Microsoft SQL Server Native Client 10.0: 공유 메모리 공급자: 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%가 중요한 효과라고는 말할 수 없습니다.

문제

포럼에서 동일한 질문이 지속적으로 제기됩니다. 1C + MSSQL이 파일보다 쿼리를 더 느리게 처리하는 이유는 무엇입니까?

그런 다음 일반적으로 수십 페이지에 대한 "홍수"가 있습니다.

이러한 포럼에는 두 가지 인기있는 "현재"가 있습니다. 일부는 이것이 클라이언트-서버 버전의 경우 정상이라고 말하고 파일 버전은 항상 더 빠르게 작동해야 하며 다른 일부는 1C가 subd와 잘 작동하지 않는다고 말합니다.

포럼에서 "전투와 대결"의 결과로 사람들은 자신의 의견에 동의하지 않습니다.

우리는 질문을 몇 가지로 나눌 것을 제안합니다.

1. 파일 버전의 활동이 데이터베이스의 다른 사용자와 독립적인 경우 "독점적" 작업에서 파일 버전이 더 빠르게 작동합니까?

"독점적 성격"이란 정보베이스에서 한 명의 활성(작업) 사용자를 의미합니다.

2. 사용자가 자원을 놓고 적극적으로 경쟁할 때(예: 상품을 판매할 때 한꺼번에 재고에 액세스할 때) 다중 사용자 모드에서 파일 버전이 더 빠르게 작동합니까?

3. 비즈니스 관점에서 볼 때 파일 버전과 클라이언트-서버 버전 간의 속도 차이는 얼마나 중요합니까?

정말 무엇입니까

테이블 번호 1. 파일과 클라이언트-서버 버전 1C의 비교

첫 번째 질문에 대한 답변: 활동이 데이터베이스의 다른 사용자에 의존하지 않을 때 파일 버전이 "독점적 성격"의 작업에서 더 빠르게 작동합니까? 확률은 99%입니다. 파일 버전이 더 빠름(기능이 실패한 하드웨어로 제한되지 않고 파일 버전의 최대 기능에 도달하지 않은 경우)!.

우리의 말을 믿지 마십시오. 직접 확인하십시오. 가져가서(자세한 설명은 여기) 직접 확인하십시오(먼저 파일 버전을 확인한 다음 클라이언트-서버 버전을 확인하십시오).

테스트를 믿을 수 없다면 파일 및 클라이언트-서버 버전에서도 테스트하기에 적합하다고 생각되는 작업을 테스트하십시오. 예를 들어 최대 4GB 크기의 데이터베이스에 대한 "월 마감"을 기준으로 삼는 것이 좋습니다(그렇지 않으면 파일 버전에서 크기 제한에 도달할 수 있음).

파일 버전에서 월을 마감할 수 없다면 파일 버전의 장점에 대해 논의할 필요가 없다는 것이 분명합니다. 동의하십니까?

또 다른 중간 질문이 발생합니다.

그리고 클라이언트-서버의 파일 버전은 숫자로 얼마나 빠릅니까?

이 질문에 대한 대답은 훨씬 더 흥미롭고 실용적입니다. 우리의 테스트 및 연습 쇼:

1. 측정 가능한 데이터 볼륨에 대한 평균 통계 작업에서 거의 2배 더 빠름
2. 평균 작업에서 데이터 볼륨이 사용 가능한 RAM 양을 초과하기 시작하고 페이징 강도가 증가할 때(최대 3-4배 더 빠름) 이는 한 달을 마감하는 예일 뿐입니다.

그러나 "평균" 작업이 무엇인지 이해하는 것이 중요합니다. 클라이언트-서버 버전에서 RAM의 데이터에 대해 작동하는 작업은 손실되지 않으며 때로는 파일 버전을 이기는 것으로 나타났습니다!

그러나 그러한 작업은 거의 없으며 표시되지 않습니다. 기본 부하는 데이터를 읽고 가장 중요하게는 쓰기를 위해 실제로 디스크 하위 시스템에 액세스하는 작업으로 구성됩니다.

또한 무해한 보고서라도 MS SQL Server가 사용되는 경우 예를 들어 tempdb 서비스 데이터베이스에 구성 중에 데이터를 쓸 수 있습니다.

파일 버전에서 요청을 실행할 때 1C 서버 형태의 데이터 중개자가 없습니다. 요청 통과의 한 세그먼트가 적습니다. 예를 들어 "중개자 없이 작업"을 수행하는 경우 "중개자와 작업"보다 항상 빠르다는 것은 논리적입니다. 예를 들어 쿼리를 실행할 뿐만 아니라 다른 요청 작업에 더 나은 병렬 처리를 제공하는 데 필요합니다. 하다. 전체 테이블에 잠금을 적용하는 것이 더 쉽습니다. 이것은 잠금에 대한 정보가 있는 하나의 레코드이고 수천 개의 행을 잠그는 것은 훨씬 더 많은 추가 레코드이지만 더 중요한 것은 훨씬 더 많은 리소스(프로세서, 메모리, 때로는 디스크 공간).

다시 말해서, 클라이언트-서버 버전은 동일한 작업에 대해 볼륨 측면에서 파일 버전보다 더 많은 리소스를 필요로 합니다..

따라서 동일한 컴퓨터에서 클라이언트-서버(동일한 독점 모드)보다 파일 버전의 독점 모드에서 더 많은 작업을 수행할 수 있습니다.

결과적으로 클라이언트-서버 옵션이 더 적은 작업을 수행할 수 있고 더 많은 리소스가 필요한 것처럼 보이지만 "이익"은 어디에 있으며 거의 ​​모든 곳에서 사용되는 이유는 무엇입니까?

우리 기사의 두 번째 질문은 우리가 대답하는 데 도움이 될 것입니다. 사용자가 자원을 위해 적극적으로 경쟁할 때(예: 상품을 판매할 때 대량으로 재고 잔고에 액세스할 때) 다중 사용자 모드에서 파일 버전이 더 빠르게 작동합니까?

표 1에서 데이터베이스 크기가 작다는 파일 옵션의 중요한 단점을 볼 수 있습니다. 대부분의 기업에서 1C 데이터베이스는 수십에서 수백 기가바이트를 차지합니다. 그러나 더 중요한 것은 파일 버전이 중복 잠금(불필요)을 부과하여 사용자의 병렬 작업 가능성을 크게 줄인다는 것입니다.

예를 들어 기업에는 100명의 1C 사용자가 있습니다. 적절한 측정을 위해 하루에 각 사용자가 하루 종일 균등하게 10개의 문서를 입력하고 각 테이블 부분에 10개의 행이 있다고 가정해 보겠습니다.

우리는 간단한 산술을 얻습니다. 100 x 10 x 10 = 하루 동안 정보 시스템에 10,000 줄이 입력됩니다.

이해하기 쉽도록 각 사용자는 고유한 데이터로 작업하고 다른 사용자는 문서의 표 부분이나 세부 구성에서 서로 교차하지 않는다는 데 동의합니다.

클라이언트/서버 모드에서는 작동합니다. 문서는 병렬로 보관됩니다.

파일 모드에서 잠금의 중복성을 알면 파일 모드에서 100명의 사용자가 그날 시스템에 첫 번째 문서를 동시에 입력하지만 동시에 보류 버튼을 누르면 어떻게 되는지 계산해 봅시다.

기본 잠금 제한 시간은 20초입니다. 이론적으로 첫 번째 사용자 외에 모든 후속 사용자가 서로를 20초 동안 기다린 후 문서를 보낸다고 가정할 수 있습니다. 총 대기 시간은 사용자 100명 x 문서 1개 x 20초 = 대기 시간 2000초입니다. 느낌 - 이것은 사용자를 위한 30분의 유휴 시간입니다.

실제로는 여전히 더 슬프고 사람은 로봇이 아니며 시스템이 차단되거나 문서가 보관될 가능성이 높을 때를 보지 못하므로 단순히 시스템에 데이터를 입력할 수 없다고 말합니다. 블로킹. 또는 실제로 기업은 파일 모드에서 "일어나"게 됩니다.

그러나 놀라운 프로그래머가 기업에 와서 시도가 지속적으로 자동으로 수행되는 방식으로 프로그램을 작성했다고 상상하더라도이 30 분의 다운 타임은 아무데도 가지 않을 것입니다.

또한 2.3을 시도하면 문서가 그림을 망치고 하루 만에 이상적인 코드가 있더라도 파일 버전은 사용자 100명 x 문서 10개 x 20초 = 20,000초 ~ 5시간 30분의 중단 시간을 "누적"합니다.

5시간 - 클라이언트-서버 옵션의 핸디캡입니다. 클라이언트-서버 버전의 각 스레드에서 입력되는 속도는 중요하지 않습니다. 입력하는 것이 더 중요하며 파일 버전에서는 이때 중복 잠금 대기가 발생합니다.

중복 잠금 외에도 여전히 필요한 잠금이 있으므로 성능의 개념을 새롭게 공식화합니다.

비즈니스 관점에서 생산성은 하나의 독점이 아니라 100명의 사용자 모두가 하루에 수행하는 작업량입니다. 따라서 모든 사용자가 시스템에 얼마나 많은 데이터를 입력할지가 비즈니스에 더 중요합니다. 공동 작업의 성능을 평가하면 파일 버전은 클라이언트-서버 버전에 수십에서 수백 배 손실됩니다.

다시 말하지만, 우리의 말을 믿지 말 것을 촉구합니다. 1C:Standard Load Test http://v8.1c.ru/expert/etp.htm을 수행하거나 자체 집단 테스트를 개발하고 우리 진술의 신뢰성을 직접 확인하십시오.

테스트나 그 결과에 대해 질문이 있는 경우 포럼에서 토론할 수 있습니다.

1C: KIP를 구매할 수도 있습니다. 기능에 주의하세요.

이제 세 번째 질문에 답해 보겠습니다. 비즈니스 관점에서 볼 때 파일 버전과 클라이언트-서버 버전 간의 속도 차이는 얼마나 중요합니까?

파일 버전은 독점 모드에서 클라이언트-서버 버전보다 약간 앞서고 다중 사용자 모드에서는 매우 크게 손실됩니다.

그러나 비즈니스에는 거의 항상 우선 순위가 더 높은 다른 작업, 즉 내결함성, 중단 없는 운영, 안정성 및 안정성이 있다는 것을 이해해야 합니다. 장애 조치 클러스터에서 서버를 실행하려면 데이터 미러링을 위한 추가 비용이 필요합니다. 따라서 성능, 안정성, 보안 등 다양한 작업 간에 항상 균형이 유지되어야 합니다.

파일 버전에는 데이터 무결성 제어 메커니즘이 없습니다. 예를 들어, 데이터 전송 중에 네트워크 오류가 발생하거나 표시등이 꺼지면 파일 버전에서 기록할 시간과 그렇지 않은 시간이 있습니다. 데이터 무결성이 파괴됩니다. 클라이언트-서버 버전에서는 이러한 경우 불완전한 트랜잭션이 롤백되고 불완전한 데이터가 시스템에 입력되지 않고 데이터 무결성이 유지됩니다.

저것들. 시스템의 사용자 수가 많을수록 파일 버전이 클라이언트-서버 버전에서 더 많이 손실되므로 실패 시 데이터 복구 절차는 파일 버전을 완전히 손실되는 옵션으로 바꿉니다.

이제 "올바른 질문"을 해야 합니다.

4. 파일 속도와 클라이언트-서버 옵션의 차이를 평가하기 위해 질문이 발생한 이유는 무엇입니까?

포럼에서 동일한 서신 및 홍수는 질문자가 클라이언트-서버 버전에서 성능 문제가 있다는 사실로 시작됩니다.

그러나 그는 클라이언트-서버 버전에서 문제를 일으킨 원인을 연구하는 대신 파일 버전에서는 그런 문제가 없음을 발견합니다. 그는 문제가 파일 버전에 없는 "중개자"에 있을 수 있다고 걱정하지 않습니다.

정답은 파일 또는 클라이언트-서버 옵션이 얼마나 빠른지는 중요하지 않지만 중요한 것은 각 특정 사례에서 속도 저하의 원인이 정확히 무엇인지입니다. PERFORMANCE라는 단어는 실제로 이 성능을 함께 형성하는 시스템의 작업 목록으로 작성되어야 하기 때문에 위험합니다. 속도 저하에 가장 많이 기여하는 작업부터 시작하여 각 작업을 고려해야 합니다.

일반적으로 우리는 이 작업을 수년 동안 전문적이고 성공적으로 수행해 왔습니다.

솔루션 비용을 추정하기 위해 무료로 느리게 작동하는 특정 작업을 살펴볼 준비가 되었습니다. 조건과 가격이 귀하에게 적합하면 작업 속도를 높이고 귀하가 지정한 조건에 도달하면이 경우에만 작업 비용을 지불합니다.

1C의 작동 모드에 대한 몇 가지 질문이 생겼습니다.

정보베이스 작업 모드:
작품의 파일 버전
클라이언트 - 작업의 서버 버전

파일 작동 모드

작품의 파일 버전은 한 사용자의 개인적인 작업을 위해 설계되었지만 네트워크를 통한 다중 사용자 작업도 가능합니다. 이 모드에서는 문서의 병렬 게시가 불가능합니다. 평균적으로 약 10명의 사용자가 파일 모드에서 동시에 작업할 수 있습니다.
서버 키 구매가 필요하지 않습니다.
파일 작동 모드에서 전체 정보 베이스(데이터베이스, 구성)는 파일에 저장됩니다. 1Cv8.1CD.

1Cv8.1CD는 파일 데이터베이스입니다.

파일 데이터베이스(파일 1Cv8.1CD)는 File DBMS에서 관리합니다., 1C:Enterprise 플랫폼의 일부입니다.
파일 모드에서는 클라이언트-서버 작동 모드를 모방하므로 여전히 클라이언트-서버 개발 메커니즘을 고수해야 합니다.

1Cv8.1CD 파일이 4GB보다 큰 경우. 클라이언트-서버 버전의 작업으로 전환하는 것에 대해 생각할 때입니다.

파일 작업 모드의 큰 단점은 낮은 정보 보안입니다.

파일 버전의 작업 계획

씩 클라이언트 애플리케이션은 정보 베이스에 직접 액세스하고 응답을 받습니다. 또한 씬 클라이언트는 자체 프로토콜을 사용하여 데이터베이스에 직접 액세스합니다. 웹 클라이언트는 웹 서버를 사용하여 정보 베이스에 액세스합니다.

파일 모드에서 클라이언트-서버 모드로 전환하려면 infobase를 dt 형식으로 업로드한 다음 서버에 생성된 infobase에 업로드하면 됩니다.

클라이언트-서버 작업

클라이언트-서버 옵션은 다수의 사용자 정보 베이스 작업에 적합합니다. 데이터베이스의 신뢰성은 자동 아카이빙 및 복구 메커니즘을 포함하는 DBMS에 의해 보장됩니다. 데이터 작업 속도는 파일 작업 모드보다 빠릅니다.

클라이언트-서버 버전은 3계층 아키텍처에 따라 작동합니다.
사용자
애플리케이션 서버(서버 클러스터)
DBMS

클라이언트는 사용자의 요청을 작업 서버로 리디렉션하는 클러스터 관리자에 연결합니다(요청은 더 자유로운 서버로 리디렉션될 수 있음). 다음으로 서버는 필요한 데이터를 얻기 위해 DBMS를 호출합니다.
DBMS는 요청을 처리하고 처리된 데이터를 클라이언트에 반환하는 서버에 데이터 배열을 반환합니다. 서버 클러스터에서는 작업 서버 장애 시 프로세스가 전송되는 중복 서버를 구성할 수 있습니다. 이것은 신뢰성을 향상시킵니다.

웹 클라이언트는 http 프로토콜을 통해 서버 클러스터에 액세스하는 웹 서버와 상호 작용합니다. http 프로토콜을 사용하여 씬 클라이언트로 작업하는 것도 가능합니다(정확히 동일한 체계에 따름).

현재 작동 모드구성 프로그램과 사용자 모드에서 다음을 열어서 볼 수 있습니다. 도움말 -> 정보(라인 "모드")

일반 응용 프로그램은 항상 씩 클라이언트 모드에서 실행됩니다. 관리형 애플리케이션은 씩 클라이언트와 씬 클라이언트 모두에서 실행할 수 있습니다. 씬 클라이언트의 기능은 심각하게 제한됩니다.

일반 및 관리 애플리케이션, 일반 및 관리 1C:Enterprise 양식에 대한 기사는 여기에서 찾을 수 있습니다.

의견을 남겨주세요. 귀하의 의견을 소중하게 생각합니다.

추신 찰리 브루커 - 위시 박스