Максимальне використання процесора

Мій сценарій - це пересічні лінії з багатокутниками. Це довгий процес, оскільки налічується понад 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)

Моє запитання: чи є спосіб змусити ЦП працювати на 100%? Він працює на 25% весь час. Я думаю, що сценарій працював би швидше, якби процесор був на 100%. Неправильне відгадування?
Моя машина:

• Windows Server 2012 R2 Standard
• Процесор: процесор Intel Xeon E5-2630 0 @ 2.30 GHz 2.29 GHz
• Встановлена ​​пам'ять: 31,6 ГБ
• Тип системи: 64-бітна операційна система, процесор на основі x64

Дозвольте мені здогадатися: ваш процесор має 4 ядра, тому 25% використання процесора - це 100% використання одного ядра та 3 непрацюючих ядра.

Тож єдине рішення - зробити код багатопотоковим, але це не проста задача.

Я не дуже впевнений, що це завдання, пов'язане з процесором. Я думаю, це буде операція, пов'язана з входом / виводом, тому я б хотів використати найшвидший диск, до якого я мав доступ.

Якщо E: це мережевий накопичувач, то усунення це було б першим кроком. Якщо це не високопродуктивний диск (<7 мс шукати), то це було б другим. Ви можете досягти певної вигоди від копіювання шару полігону в in_memoryробочу область, але вигода може залежати від розміру класу функцій полігону та від того, чи використовуєте ви 64-бітну обробку фону.

Оптимізація пропускної здатності вводу / виводу часто є важливою для продуктивності ГІС, тому я рекомендую вам приділяти менше уваги вимірювальному процесору та більше уваги мережевим та дисковим вимірювачам.

У мене були подібні проблеми щодо продуктивності щодо архівних скриптів, головне вузьке місце - це не процесор, це жорсткий диск, якщо ви використовуєте дані з мережі, що є найгіршим сценарієм, спробуйте перенести свої дані на SSD-диск, а потім запустіть свій скрипт з командного рядка не від pyscripter, pyscripter трохи повільніше, тому що він містить деякі налагоджувальні матеріали, якщо вас знову не влаштовує, подумайте про паралельне встановлення сценарію, тому що кожен потік python займає одне ядро ​​процесора, ваш процесор має 6 ядер, тому ви можете запустити 6 сценаріїв одночасно.

Оскільки ви використовуєте python і, як було запропоновано вище, розгляньте можливість використання багатопроцесорної обробки, якщо ваша проблема може працювати паралельно.

Я написав невелику статтю на веб-сайті geonet про перетворення сценарію python в інструмент сценарію python, який можна було б використати в модельєрі. Документ перераховує код і описує деякі підводні камені для його запуску як інструменту сценарію. Це лише одне місце, щоб почати шукати:

https://geonet.esri.com/docs/DOC-3824

Як було сказано раніше, слід використовувати багатообробку або нарізування різьби . Але тут випливає застереження: Проблема повинна бути розділеною! Тому подивіться на https://en.wikipedia.org/wiki/Divide_and_conquer_algorithms .

Якщо ваша проблема ділиться, ви б походили так:

• Створіть чергу, де ви зберігаєте вхідні дані для процесів / потоку
• Створіть чергу, де зберігаються результати
• Створіть функцію або клас, який можна використовувати як процес / потік, який вирішує нашу проблему

Але, як сказав Geogeek, це може бути не проблема обмеження процесора, а проблема IO. Якщо у вас є достатня кількість оперативної пам’яті, ви можете попередньо завантажити всі дані, а потім обробити їх, що має перевагу в тому, що дані можна прочитати за один раз, таким чином, не завжди перериває процес обчислення.

Я вирішив перевірити його, використовуючи 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

Найцікавіше, що це зайняло лише 87 секунд, використовуючи інструмент геообробки від mxd. Можливо, щось не так у моєму підході до басейну ...

Як видно, я використав досить некрасивий FID-запит у (0, 4, 8,12… 500000), щоб зробити завдання поділеним.

Можливо, що запит на основі попередньо обчисленого поля, наприклад CFIELD = 0, значно скоротить час.

Я також виявив, що час, про який повідомляють багатопроцесорні інструменти, може сильно відрізнятися.

Я не знайомий з PyScripter, але якщо він підтримується CPython, то вам слід перейти до багатопроцесорної роботи, а не до багатопотокової, доки сама проблема не поділяється (як це вже згадували інші).

CPython має Global Interpreter Lock , який скасовує будь-які переваги, які у вашому випадку можуть принести кілька потоків .

Напевно в інших контекстах потоки python корисні, але не у випадках, коли ви пов'язані з процесором.

Моє запитання: чи є спосіб змусити ЦП працювати на 100%

Оскільки у вашого процесора є декілька ядер, ви лише збільшите максимальну ядро, на якому працює ваш процес. Залежно від налаштування вашого чіпа Xeon, він буде працювати до 12 ядер (6 фізичних та 6 віртуальних з увімкненою гіпертетизацією). Навіть 64-бітний ArcGIS насправді не в змозі скористатися цим - і це може призвести до обмеження процесора, коли ваш єдиний потоковий процес максимізує основну функцію. Вам потрібна багатопотокова програма для розподілу навантаження по ядрах АБО (набагато простіше) ви можете зменшити кількість ядер, на яких працює ваш процесор, щоб збільшити пропускну здатність.

Найпростіший спосіб зупинити обмеження процесора (і переконатися, що це дійсно обмеження процесора, а не обмеження на диск / введення) - це змінити параметри BIOS для вашого Xeon і встановити його на одне масивне єдине ядро. Підвищення продуктивності буде значним. Просто пам’ятайте, що це також значно торгує вашими ПК багатоцільовими можливостями, тому найкраще, якщо у вас є спеціальна технологічна машина для її здійснення. Це набагато простіше, ніж намагатися вкласти багатопотоковий код - який більшість функцій ArcGIS Desktop (як на 10.3.1) так чи інакше не підтримує.