내 스크립트는 선을 다각형과 교차합니다. 3000 개 이상의 선과 500000 개 이상의 다각형이 있기 때문에 긴 프로세스입니다. PyScripter에서 실행했습니다.
# Import
import arcpy
import time
# Set envvironment
arcpy.env.workspace = r"E:\DensityMaps\DensityMapsTest1.gdb"
arcpy.env.overwriteOutput = True
# Set timer
from datetime import datetime
startTime = datetime.now()
# Set local variables
inFeatures = [r"E:\DensityMaps\DensityMapsTest.gdb\Grid1km_Clip", "JanuaryLines2"]
outFeatures = "JanuaryLinesIntersect"
outType = "LINE"
# Make lines
arcpy.Intersect_analysis(inFeatures, outFeatures, "", "", outType)
#Print end time
print "Finished "+str(datetime.now() - startTime)
내 질문은 : CPU를 100 %로 작동시키는 방법이 있습니까? 항상 25 %로 실행됩니다. 프로세서가 100 %이면 스크립트가 더 빨리 실행될 것 같습니다. 틀린 추측?
내 기계는 :
- Windows Server 2012 R2 표준
- 프로세서 : Intel Xeon CPU E5-2630 0 @ 2.30 GHz 2.29 GHz
- 설치된 메모리 : 31,6 GB
- 시스템 유형 : 64 비트 운영 체제, x64 기반 프로세서
답변
귀하의 CPU에는 4 개의 코어가 있으므로 25 %의 CPU 사용량은 1 개의 코어 사용률과 3 개의 유휴 코어입니다.
따라서 솔루션 만 코드를 다중 스레드로 만드는 것이지만 간단한 작업은 아닙니다.
답변
이것이 CPU 바운드 작업인지 확실하지 않습니다. 나는 그것이 I / O 바운드 작업이라고 생각하므로 액세스 할 수있는 가장 빠른 디스크를 사용하려고합니다.
E :가 네트워크 드라이브 인 경우이를 제거하는 것이 첫 번째 단계입니다. 고성능 디스크가 아닌 경우 (<7ms 탐색), 두 번째입니다. 다각형 레이어를 in_memory작업 영역에 복사하면 이점이 있지만 다각형 기능 클래스의 크기와 64 비트 백그라운드 처리 사용 여부에 따라 이점이있을 수 있습니다.
I / O 처리량 최적화는 종종 GIS 성능의 핵심이므로 CPU 미터에 대한 관심을 줄이고 네트워크 및 디스크 미터에 더 많은 관심을 기울이는 것이 좋습니다.
답변
나는 arcpy 스크립트와 관련하여 비슷한 성능 문제가 있었으며, 주요 병목 현상은 CPU가 하드 드라이브가 아니라 최악의 시나리오의 네트워크에서 데이터를 사용하는 경우 데이터를 SSD 드라이브로 이동 한 다음 명령 줄에서 스크립트를 시작하십시오. pyscripter가 아닌 pyscripter는 디버깅 속도가 약간 느려서 약간 느릴 수 있습니다. 다시 만족하지 않으면 스크립트 병렬화에 대해 생각하십시오. 각 Python 스레드에는 하나의 CPU 코어가 필요하고 CPU에는 6 코어가 있으므로 시작할 수 있습니다 동시에 6 개의 스크립트.
답변
파이썬을 사용하고 위에서 제안한 것처럼 문제를 병렬로 실행할 수 있으면 멀티 프로세싱을 사용하는 것이 좋습니다.
지오넷 웹 사이트에서 파이썬 스크립트를 모델 빌더 내에서 사용할 수있는 파이썬 스크립트 도구로 변환하는 것에 관한 작은 기사를 썼습니다. 이 문서는 코드를 나열하고 코드를 스크립트 도구로 실행하기위한 몇 가지 함정을 설명합니다. 이것은 찾기 시작하는 한 곳입니다.
https://geonet.esri.com/docs/DOC-3824
답변
앞서 언급했듯이 멀티 프로세싱 이나 스레딩 을 사용해야합니다 . 그러나 여기에주의가있다 : 문제는 나눌 수 있어야한다! https://en.wikipedia.org/wiki/Divide_and_conquer_algorithms를 살펴보십시오 .
문제가 나눌 수 있으면 다음과 같이 진행하십시오.
- 프로세스 / 스레드에 대한 입력 데이터를 저장할 큐를 만듭니다.
- 결과가 저장된 대기열을 만듭니다.
- 문제를 해결하는 프로세스 / 스레드로 사용할 수있는 함수 또는 클래스 만들기
그러나 geogeek이 말했듯이 CPU 제한 문제가 아니라 IO 문제 일 수 있습니다. 충분한 RAM이 있으면 모든 데이터를 미리로드 한 다음 처리 할 수 있습니다. 즉, 한 번에 데이터를 읽을 수 있으므로 항상 계산 프로세스가 중단되지는 않습니다.
답변
21513 라인과 498596 다각형을 사용하여 테스트하기로 결정했습니다. 이 스크립트를 사용하여 다중 프로세서 접근 방식 (시스템의 12 개 프로세서)을 테스트했습니다.
import arcpy,os
import multiprocessing
import time
t0 = time.time()
arcpy.env.overwriteOutput = True
nProcessors=4
folder=r'd:\scratch'
def function(inputs):
nGroup=inputs[0]
pGons=inputs[1]
lines=inputs[2]
outFeatures = '%s%s%s_%i.shp' %(folder,os.sep,'inters',nGroup)
fids= tuple([i for i in range(nGroup,500000,nProcessors-1)])
lyr='layer%s'%nGroup
query='"FID" in %s' %str(fids)
arcpy.MakeFeatureLayer_management(pGons,lyr,query)
arcpy.Intersect_analysis([lines,lyr], outFeatures)
return outFeatures
if __name__ == "__main__":
inPgons='%s%s%s' %(folder,os.sep,'parcels.shp')
inLines='%s%s%s' %(folder,os.sep,'roads.shp')
m,bList=0,[]
for i in range(nProcessors):
bList.append([i,inPgons,inLines])
pool = multiprocessing.Pool(nProcessors-1)
listik=pool.map(function, bList)
## apply merge here
print listik
print ('%i seconds' %(time.time()-t0))결과, 초 :
- 일반 로컬 하드 드라이브-191
- 초고속 로컬 드라이브-220
- 네트워크 드라이브-252
mxd의 지오 프로세싱 도구를 사용하면 87 초 밖에 걸리지 않습니다. 아마도 수영장에 대한 접근 방식에 문제가있을 것입니다 …
보시다시피 (0, 4, 8,12… 500000)에서 추악한 쿼리 FID를 사용하여 작업을 나눌 수있게했습니다.
미리 계산 된 필드를 기반으로하는 쿼리 (예 : CFIELD = 0)는 시간을 크게 단축시킬 수 있습니다.
또한 멀티 프로세싱 도구에서보고 한 시간이 크게 다를 수 있다는 것을 알았습니다.
답변
나는 PyScripter에 익숙하지 않지만 CPython에 의해 뒷받침된다면 문제 자체가 나눌 수있는 한 (다른 사람들이 이미 언급했듯이) 멀티 스레딩을하지 않아야합니다.
CPython에는 Global Interpreter Lock이 있어 여러 스레드가 귀하의 경우에 가져올 수있는 모든 이점을 제거합니다 .
다른 맥락에서 파이썬 스레드는 유용하지만 CPU에 묶여있는 경우에는 유용하지 않습니다.