• 台灣杉三號的專屬保證資源(保留佇列RQ與限時保留佇列RTSQ)與台灣杉一號(Taiwania 1)專屬計算資源有何不同?
    相同:保證用戶於租用時段內,可即時取用租用的所有計算資源。
    不同:
    (1)台灣杉一號專屬計算資源係租用固定的計算節點且計算核心數有級距限制,當計算資源閒置時,無法服務其他用戶。
    (2)台灣杉三號的保留佇列(RQ)與限時保留佇列(RTSQ),除有租用計算核心數最小與最大值限制外,其他無限制,計算資源依核心數動態調撥,非採用固定專用節點,讓計算資源租用更具彈性,且若有資源閒置時,可釋出提供其他用戶服務,使有限的計算資源得以充分利用,不致造成閒置浪費。
  • 保留佇列、限時保留佇列與非保留佇列的執行優先權有何不同?
    保留佇列與限時保留佇列擁有最高的執行優先權;其中非保留佇列屬較低執行優先權。

  • 保留佇列用戶若臨時有大於租用計算資源的短期性的計算需求,該怎麼辦?
    若保留佇列用戶使用量已達租用資源的上限後,還有額外的計算需求時,除了繼續於租用的保留佇列中排隊等候使用外;亦可至非保留佇列提交計算工作,但須依非保留佇列系統排程政策排隊使用,此計算工作採非保留佇列費率計費。

  • 為何台灣杉三號申請RQ/RTSQ不需要像台灣杉一號要有設定費?
    因台灣杉一號為固定的專用節點,須等待調撥節點上的計算工作清空,在聚集足夠的計算資源後,方能提供租用戶服務,在此之前調撥的計算資源無法提供服務,增加系統維運成本;台灣杉三號保留佇列/限時保留佇列,資源調撥非屬固定節點,無需等待計算工作結束的服務空窗期間,且若租用戶有閒置資源時,這些計算資源亦可提供NRQ服務,不會造成計算資源閒置與浪費。
  • 保留佇列與限時保留佇列取用資源的原則為何?
    保留佇列的計算資源會優先使用當時系統閒置的計算資源,不足時會由非保留佇列最低優先權的佇列取用,取用資源依影響數量最少的計算工作為原則。
  • 一般用戶(NRQ)在台灣杉三號上相較於在以往的系統上,會有什麼影響?
    可能會有如下的幾種狀況發生:
    •保留佇列使用率低,釋出閒置資源,非保留佇列有更多計算資源可用,等待時間大幅減少。
    •保留佇列使用率穩定,與以往情況相同,非保留佇列計算工作未發生中斷重新計算的情形。
    •保留佇列使用率不定  ,非保留佇列計算工作可能會發生運算到一半被中斷,重新進入排程系統排隊,被requeue的機率視RQ用量與使用率而定,發生requeue後,整體的計算時間可能會比較長。
    •與以往系統比較,一般用戶的使用費率相對較為便宜,因此對一般用戶仍是相對有利的。
  • 我的計算工作算到一半被中斷,重新排隊等候計算,請問發生了什麼事?計算費用要怎麼算?
    若系統資源不足,則執行中NRQ工作因不具優先序,有可能被中斷。此時,該工作中斷前的使用量不會計費,且被中斷的工作將由系統自動派送重新排隊等候重新從頭計算,此時此工作將具有優先序,預設會自動重新排隊,在非保留佇列中有較高的執行優先權。
  • 我使用中的計算資源被徵用,計算工作被強迫中斷,但不想系統自動重新排隊(計算工作特殊,無法requeue重新計算),請問該怎麼做?
    因為計算資源不足,造成您的計算工作中斷,造成不便之處,我們深感抱歉!若您不願意系統幫您requeue的話,可在job script中加入 "#SBATCH --no-requeue",即可取消自動requeue的設定。如:

    #SBATCH -A GOV109109
    #SBATCH -p ct224
    #SBATCH -n 224
    #SBATCH -c 1
    #SBATCH --no-requeue
    #SBATCH -o  %j.out

    mpirun ......
  • 是否可能避免計算資源被徵用,造成計算中斷的情況發生?
    可以的,您可申請使用保留佇列RQ或限時保留佇列RTSQ,就一定不會有因為計算資源不足造成計算中斷的情況發生。
  • 該如何查看我的計算工作是否曾被徵用過?
    您可以使用 sacct 指令來查詢,如:
    $ sacct -D -j 98701 -o JobID,Start,End,Stat
    State出現PREEMPTED,即表示曾被徵用計算資源。

  • 我的計算工作發生過requeue,請問是被保留佇列RQ或限時保留佇列RTSQ的工作徵用嗎?
    台灣杉三號的SLURM預設是requeue enable,當您的計算工作因系統問題(如:檔案系統、硬體問題、網路問題...等),而計算失敗時,系統會自動將失敗的計算工作重新submit到SLURM裏排隊計算,job_id維持一樣。因此當您發現計算工作requeue,並不一定是計算資源被徵用,有可能是系統問題導致的,確認方法如前述說明,只有狀態是PREEMPTED才是被徵用的情況。
  • 我在台灣杉3號上使用非保留佇列的計算(NRQ)跑程式,但是跑到一半出現類似"slurmstepd: error: * JOB XXX ON cpnXXX CANCELLED AT 2021-08-20T18:58:18 DUE TO PREEMPTION * " ,請問這是怎樣的錯誤?
    因高執行優先權的保留佇列(RQ)計算工作徵用您位於非保留佇列(NRQ)的計算工作使用節點。被徵用計算資源導致中斷的計算工作,在計算中斷前的使用量不會計費,且該計算工作將自動派送至系統,排隊等候再次計算,此時此工作將具有優先序,在非保留佇列中有較高的執行優先權。目前系統設定若因硬體異常、計算資源被徵用等情況,會安排異常中斷的計算工作自動進入系統排隊等候執行,若您的計算工作不適合這種重新計算的行為,請務必在job script中加上--no-requeue的選項。
  • HFS 如何分享目錄 / 檔案?#指定特定的使用者或群組分享
    UNIX/Linux 檔案權限表示方式
    傳統的UNIX檔案權限分為三個部分,使用ls -l可以看到類似如下的資訊:
    -rwxr--r--   1 root root       9216 Feb 25 15:02 test.sh
    各欄位意義:
    第一欄(-rwxr--r--):表示檔案/目錄的權限。第一字元若為d,即表示目錄;若為-,則為檔案。
    第二欄(1):表示link的數目,通常是hard link
    第三欄(root):檔案/目錄的擁有者,此例為root
    第四欄(root):檔案/目錄所屬群組(group),此例為root的群組
    第五欄(9216):檔案大小,此例為9216 bytes
    第六欄(Feb 25 15:02):檔案的建立或最後一次異動修改時間
    第七欄(test.sh):檔案/目錄名稱,此例檔名為test.sh

    第一欄的第一字元表示目錄或檔案,第二字元起,每三個一組,分別代表user(即owner)、group與other的權限,非屬於owner與group的成員,都歸屬於other。若為檔案,r為讀取、w為寫入、x為執行權限;若為目錄,r為讀取、w為寫入(包含建立與刪除檔案)、x為進入該目錄的權限。
    ---(0):無任何權限
    --x(1):僅具執行或進入的權限
    -w-(2):僅具寫入(刪除)權限
    -wx(3):具進入與寫入或刪除權限
    r--(4):僅具讀取權限
    r-x(5):具進入或執行和讀取權限
    rw-(6):具讀取或寫入(刪除)權限
    rwx(7):具完整權限

    分享檔案/目錄權限的方式有三,前二種是利用傳統UNIX/Linux的檔案權限方式就可以達成,第三種為比較精細的Access Control List方式,於Microsoft Windows中的檔案權限控制就是採用這種方式,可指定分享的檔案/目錄分享給指定的用戶或群組:

    一、檔案/目錄權限全開
    利用chmod 777 $file 或chmod 777 $directory,將檔案/目錄權限全部開放,也就是所有人都可以讀、寫,此一分享方式最危險,毫無任何限制,任何人都可以存取變更您的檔案資料,請避免使用此方式。
    命令語法:
     1.chmod 777 $file 、chmod 777 $directory
     2.chmod a+rwx $file或 chmod a+rwx $directory

    1與2的語法效果一樣,其中2使用的a為all的意思,其值可為u、g、o與a,分別代表user、group、other與all。

    如:
    chmod 777 /work/user
    chmod a+rwx /work/user


    二、對目錄設定setgid
    設定目錄setgid bit,可讓所有在此目錄下新建立的檔案/目錄都屬於同一個群組,只要開放該檔案/目錄的群組權限,就可以分享資料
    命令語法:
    1.chmod 2750 $directory
    2.chmod g+s $directory

    如:
    $ chmod 2750 /path/to/test
    $ ls -ld test
    drwxr-s--- 2 user nchc 1 Mar  4 15:47 /path/to/test

    此一方式適用於屬於同一計畫(群組)的用戶,若有多群組成員共用資料需求,建議使用第三種方式。

    三、利用Access Control List(ACL)功能
    較為先進的UNIX/UNIX-like作業系統(如:AIX、HP-UX、Solaris、*BSD、Linux..)與檔案系統都有支援ACL,以下簡述其用法:

    常用命令名稱:
    setfacl 設定/移除檔案/目錄的ACL權限
    getfacl 讀取檔案/目錄的ACL權限

    1.分享檔案設定範例:
    a) userA 設定fileA給userB讀取
    userA]$ setfacl -m u:userB:r fileA

    原來的fileA權限:
    userA]$ ls -l fileA
    -rw-r--r-- 1 userA groupA 1547 Sep 22 10:14 fileA

    變更後的權限:
    userA]$ ls -l fileA
    -rw-r--r--+ 1 userA groupA 1547 Sep 22 10:14 fileA

    注意:最後面多了"+"的符號,代表此目錄/檔案具ACL屬性。

    確認分享後的權限
    userA]$ getfacl fileA
    # file: fileA
    # owner: userA
    # group: groupA
    user::rw-
    user:userB:r--
    group::r--
    mask::r--
    other::r--

    b)移除分享給UserB的讀取權限
    userA]$setfacl -x u:userB fileA
    userA]$ls -l fileA
    -rw-r--r--+ 1 userA groupA 1547 Sep 22 10:14 fileA

    確認權限是否移除
    userA]$getfacl fileA
    # file: fileA
    # owner: userA
    # group: groupA
    user::rw-
    group::r--
    mask::r--
    other::r--

    c) userA 設定fileA給userB讀取、寫入
    userA]$ setfacl -m u:userB:rw- fileA

    d) userA 設定fileA給groupB讀取、寫入
    userA]$ setfacl -m g:groupB:rw- fileA

    e)若要完整移除ACL相關設定,請使用-b的參數
    userA]$ setfacl -b fileA
    userA]$ ls -l fileA
    -rw-r--r-- 1 userA groupA 1547 Sep 22 10:14 fileA

    2.目錄分享設定範例
    a)userA設定目錄dirA給groupB 讀、寫與進入(rwx)權限
    userA]$setfacl -m g:groupB:rwx dirA

    原來的權限:
    userA]$ls -ld dirA
    drwxr-x--- 2 userA groupA 6 Sep 22 10:59 dirA

    分享後:
    userA]$ls -ld dirA
    drwxrwx---+ 2 userA groupA 6 Sep 22 10:59 dirA

    確認權限是否正確
    userA]$# getfacl dirA
    # file: dirA
    # owner: userA
    # group: groupA
    user::rwx
    group::r-x
    group:groupB:rwx
    mask::rwx
    other::---


    b) userA設定目錄dirA給userB讀、寫與進入(rwx)權限
    userA]$setfacl -m u:userB:rwx dirA

    c)移除ACL設定
    userA]$setfacl -b dirA
    userA]$ls -ld dirA
    drwxr-x--- 2 userA groupA 6 Sep 22 10:59 dirA


    3.更多ACL設定,請man setfacl

    4. 請勿分享整個個人家目錄,除了個人資安風險外,亦會造成ssh連線問題。

  • 我在台灣杉三號上使用了224核心,為什麼是在6個節點上執行?而不是在預期的4個節點上執行?
    台灣杉三號為泛用型計算主機,提供許多領域不同需求的計算服務,每個計算工作需求核心數也不一樣,不一定會完全使用到整個節點的全部56個計算核心,因此就會出現部分節點有閒置核心的情況,造成計算資源零碎不連續分佈。為充分使用這些零碎的計算資源,大部分的排程系統都會有把計算工作派送到這些閒置核心的功能,台灣杉三號在今年(2021)8月啟用此功能。

    若您的計算工作沒有特別指定要多少節點或每個節點使用多少核心(--ntasks-per-node),那麼有些計算核心就會被分配到前述的情況的節點上,容易出現一個計算工作在不同的計算節點上有不同的使用核心數(process數),有的節點也許是1核心、有的也許是5核心等不一的情況,造成計算效能低落,甚至是出現結果偏差的情況。

    SLURM上與計算核心數/節點數比較相關且常用的設定,有以下4個:
    -n, --ntasks=<number>
    --ntasks-per-node=<ntasks>
    -c, --cpus-per-task=<ncpus>
    -N, --nodes=<nodes>

    其中--cpus-per-task(-c)預設值是1,只有在執行OpenMP(請注意:OpenMP與OpenMPI不同)計算時才需要設定,其餘時候可以忽略。
    --ntasks(-n)、--ntasks-per-node與--nodes(-N) 三者可同時使用或單獨使用,各有不同意義。
    a.只指定--ntasks=n,也就是只要mpi processes是n個,不管在幾個節點上執行都可。
    b.指定--ntasks=n和--ntasks-per-node=b,每個節點執行b個mpi process,mpi processes總數為n;若不為倍數,最後一個節點上的mpi process數目為餘數
    c.指定--ntasks=n和--nodes=N,n個mpi processes平均在N個節點上執行
    d.指定--ntasks-per-node=b和--nodes=N,在每個節點上執行b個mpi processes,於N個節點上執行,共有bxN個mpi processes

    範例:
    1.只指定--ntasks=220,可能會在4個以上的節點上執行。
    2.指定--ntasks=220、--ntasks-per-node=56,共會在4個節點上執行,其中三個節點有56個processes、一個是52個processes
    3.指定--ntasks=220、--nodes=4,共會在4個節點上執行,每個節點執行55個processes。
    4.指定--ntasks-per-node=56、--nodes=4,共會在4個節點上執行,每個節點執行56個processes,共有56x4=224個processes

    綜合上述,請依照您的計算模式需求撰寫job script設定,以免出現計算工作派送不如預期的情況,造成您的計算額度浪費。

  • 台灣杉三號上的NRQ使用方式,是否有侵害到RQ用戶的權益?
    台灣杉三號使用新的排程軟體Slurm,透過其先進的功能,可以提供用戶保留優先佇列(Reserved Queue, RQ),亦即用戶擁有優先權,但不是固定在某幾個節點,也就是900個節點隨需要的時候,可以彈性調度,這是迥異於台灣杉一號的包機方式,故台灣杉三號的RQ不是等同台灣杉一號的包機(固定主機)作法。

    NRQ (Non-Reserved Queue)用戶取用系統閒置CPU核心進行計算,RQ用戶需要時,可隨時取用其租用的核心數使用,因此,NRQ的使用,並不會侵害到RQ用戶的權益。同理,RTSQ (Reserved Time Slot Queue)與RQ一樣的機制,只是在特定時段使用RQ,所以,一樣不會被NRQ的使用而被侵害到相關權益。
  • 如何在Slurm下查看計算⼯作記憶體⽤量?
    計算⼯作的記憶體最⼤⽤量,可以參考slurm的MaxRSS
    ◆執⾏中的計算⼯作
    可以使⽤sstat指令查閱⽬前計算⼯作狀態,如sstat --format=JobID,NTasks,MaxRSS,MaxRSSNode -j $job_id
    詳細⽤法可man sstat


    ◆執⾏完畢的計算⼯作
    使⽤sacct 查閱計算過程中各項數據,如sacct -o
    jobid,jobname%12,partition,user%16,NCPUS,AllocNodes,MaxRSS,Start,End,Elapsed,state-j $job_id
    備註:%nn,表⽰該欄位顯⽰字元寬度,如%12,代表顯⽰寬度為12個字元
  • 請問為什麼計算節點上明明就還有28個閒置核心可用,為什麼20核心的計算工作無法進入執行?怎麼讓二個計算工作在同一個節點裡面執行?
    計算節點可否再接受計算工作的主要因素,為剩餘計算資源是否足夠。台灣杉三號安排計算工作到計算節點上執行時,係依據計算工作的計算核心與記憶體需求用量進行安排。若未指定記憶體需求用量,排程系統預設將該節點所有可用的記憶體給計算工作使用,因此雖還有閒置的計算核心,但系統已無記憶體可用,無法再接受其他的計算工作。如:scontrol show job $job_id
    ...(略)
      NumNodes=1 NumCPUs=28 NumTasks=28 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
       TRES=cpu=28,mem=189816M,node=1,billing=28
    ...(略)
    可看到該節點上的記憶體已經全部安排給計算工作使用。實際的記憶體用量也許只有幾GB,不一定會用到全部,若要查詢實際計體體用量,可參考 https://iservice.nchc.org.tw/nchc_service/nchc_service_qa_single.php?qa_code=683。

    若要在一個節點裡面同時執行二個以上的計算工作,計算工作腳本(job script)就必須指定每節點的計算核心數與記憶體用量,同時二者的核心數與記憶體和,不可逾該節點可提供的最大值
    範例1:
    #!/bin/bash
    #SBATCH -A ACD110999            # Account name/project number
    #SBATCH -J test           # Job name
    #SBATCH -p ctest                  # Partiotion name
    #SBATCH -n 28                    # Number of MPI tasks (i.e. processes)
    #SBATCH -N 1            # Number of nodes
    #SBATCH --mem=40G                # Maximum memory per node to be allocated
    #SBATCH -o %j.out                # Path to the standard output file
    #SBATCH -e %j.err                # Path to the standard error ouput file

    ml compiler/intel/2021 IntelMPI/2021

     mpirun -bootstrap slurm -n $SLURM_NTASKS /path/to/program


    範例2:
    #!/bin/bash
    #SBATCH -A ACD110999            # Account name/project number
    #SBATCH -J test           # Job name
    #SBATCH -p ctest                  # Partiotion name
    #SBATCH --ntasks-per-node=28       # Number of MPI tasks per node
    #SBATCH -c 1                     # Number of cores per MPI task
    #SBATCH -N 1            # Number of nodes
    #SBATCH --mem=40000M             # Maximum memory per node to be allocated
    #SBATCH -o %j.out                # Path to the standard output file
    #SBATCH -e %j.err                # Path to the standard error ouput file

    ml compiler/intel/2021 IntelMPI/2021

     mpirun -bootstrap slurm -n $SLURM_NTASKS /path/to/program


    範例3:
    #!/bin/bash
    #SBATCH -A ACD110999            # Account name/project number
    #SBATCH -J test           # Job name
    #SBATCH -p ctest                  # Partiotion name
    #SBATCH --ntasks-per-node=28       # Number of MPI tasks per node
    #SBATCH -c 1                     # Number of cores per MPI task
    #SBATCH -N 1            # Number of nodes
    #SBATCH --mem-per-cpu=2G         # Maximum memory per CPU core to be allocated
    #SBATCH -o %j.out                # Path to the standard output file
    #SBATCH -e %j.err                # Path to the standard error ouput file

    ml compiler/intel/2021 IntelMPI/2021

     mpirun -bootstrap slurm -n $SLURM_NTASKS /path/to/program

    備註:由於系統運作與檔案系統的cache會使用一部分記憶體,為確保系統正常運作,目前開放每節點記憶體用量最多可到162400MB,實際用量超過此值,可能會導致計算失敗或系統異常。

  • job等待原因說明
    常見等待原因說明:
    Dependency:相依的計算工作尚未結束或條件尚未滿足,待條件滿足後,就會執行,請耐心等待
    QOSGrpCpuLimit:執行中的cpu核心數已達個人/計畫/群組上限,待計算工作結束釋出足夠的核心數,滿足執行件就會執行,請耐心等待
    QOSGrpJobsLimit:執行中的計算工作數已達系統/計畫上限,待執行中計算工作結束,釋出足夠的計算資源,滿足執行件就會執行,請耐心等待
    QOSMaxJobsPerUserLimit:提交的計算工作數已達用戶上限,待執行中計算工作結束,釋出足夠的計算資源,滿足執行件就會執行,請耐心等待
    QOSMinMemory:未設定記憶體用量或設定值不符最低要求,在未變更資源需求前,不會執行,建議刪除計算工作修正,記憶體用量後,重新提交
    QOSMaxMemoryPerJob:未設定記憶體用量或設定值不符最大限制,未變更資源需求前,不會執行,建議刪除計算工作,修正記憶體用量後,重新提交
    QOSMinCpuNotSatisfied:最小核心數不符合,未變更資源需求條件前,不會執行,建議刪除計算工作並修正核心數需求後,重新提交
    QOSMaxCpuPerJobLimit:核心數需求大於設定值,未變更資源需求條件前,不會執行,建議刪除計算工作並修正核心數需求後,重新提交
    PartitionTimeLimit:設定的執行時間大於該queue/partition的設定上限,未變更資源需求條件前,不會執行,建議刪除計算工作並修正執行時間後,重新提交
    Resources:目前系統資源不足,待累積足夠計算資源後,即可執行,請耐心等待
    Nodes required for job are DOWN, DRAINED or reserved for jobs in higher priority partitions:目前系統資源不足,待累積足夠計算資源後,即可執行,請耐心等待

    若欲了解更多原因說明,請man squeue,查看JOB REASON CODES章節