CPUの使用を最大化する

私のスクリプトは、ラインとポリゴンを交差させています。ライン数が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つのコアの100％の使用率と3つのアイドルコアです。

したがって、唯一の解決策は、コードをマルチスレッド化することですが、それは簡単な作業ではありません。

これがCPUに依存するタスクであることはよくわかりません。I / Oバウンドの操作になると思うので、アクセスした最速のディスクを使用したいと考えています。

E：がネットワークドライブの場合、それを排除することが最初のステップです。高性能ディスク（7ms未満のシーク）でない場合は、2番目になります。ポリゴンレイヤーをin_memoryワークスペースにコピーすることでいくつかの利点を得ることができますが、その利点は、ポリゴンフィーチャクラスのサイズ、および64ビットバックグラウンド処理を使用しているかどうかに依存する場合があります。

I / Oスループットの最適化はGISパフォーマンスの鍵となることが多いため、CPUメーターに注意を向けず、ネットワークメーターとディスクメーターにもっと注意を払うことをお勧めします。

arcpyスクリプトに関して同様のパフォーマンスの問題がありました。主なボトルネックはハードドライブのCPUではありません。最悪のシナリオであるネットワークからのデータを使用している場合は、データをSSDドライブに移動してから、コマンドラインからスクリプトを起動してください。 pyscripterからではなく、pyscripterは少し遅いです。これにはデバッグに関するものが含まれている可能性があります。満足できない場合は、スクリプトの並列化を検討してください。各pythonスレッドが1つのCPUコアを使用するため、CPUには6つのコアがあるため、起動できます。同時に6つのスクリプト。

Pythonを使用しているため、上記で提案したように、問題を並行して実行できる場合はマルチプロセッシングの使用を検討してください。

pythonスクリプトを、modelbuilder内で使用できるpythonスクリプトツールに変換することについて、geonnet Webサイトで小さな記事を書きました。このドキュメントでは、コードをリストし、スクリプトツールとして実行する際のいくつかの落とし穴について説明します。これは、探し始める1つの場所にすぎません。

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にはグローバルインタープリターロックがあります。これにより、複数のスレッドがあなたのケースにもたらす可能性のある利点がすべて取り消されます。

確かに他のコンテキストではpythonスレッドは役立ちますが、CPUに制限されている場合はそうではありません。

私の質問は：CPUを100％で動作させる方法はありますか

CPUには複数のコアがあるため、プロセスが実行されているコアのみを最大化します。Xeonチップの構成方法に応じて、最大12コア（6物理、6ハイパースレッディングを備えた仮想）で実行されます。64ビットArcGISでもこれを実際に利用することはできません。シングルスレッドプロセスが実行中のコアを使い果たすと、CPU制限が発生する可能性があります。コア全体に負荷を分散させるにはマルチスレッドアプリケーションが必要です。または（より簡単に）CPUが実行しているコアの数を減らしてスループットを向上させることができます。

CPU制限を停止する最も簡単な方法（そして、それが本当にディスク制限ではなくCPU制限であることを確認する）は、XeonのBIOS設定を変更し、1つの巨大なシングルコアに設定することです。パフォーマンスが大幅に向上します。これは、PCのマルチタスク機能のトレードオフでもあるので、これを実装する専用のプロセスマシンがある場合に最適です。これは、コードをマルチスレッド化するよりもはるかに簡単です。これは、ほとんどのArcGIS Desktop関数（10.3.1以降）はサポートしていません。