<noframes id="vddlx"><form id="vddlx"><nobr id="vddlx"></nobr></form>

    <noframes id="vddlx">
    <listing id="vddlx"><nobr id="vddlx"><meter id="vddlx"></meter></nobr></listing>
    <form id="vddlx"><th id="vddlx"><progress id="vddlx"></progress></th></form><em id="vddlx"></em>

      
      

      <listing id="vddlx"><listing id="vddlx"><menuitem id="vddlx"></menuitem></listing></listing>

        <span id="vddlx"></span>

          Linux性能優化實戰學習筆記:第二十七講

          技術標簽: Linux  linux

          Linux性能優化實戰學習筆記:第二十七講

          一、案例環境描述

          1、環境準備

          2CPU,4GB內存

          預先安裝docker sysstat工具

          2、溫馨提示

          案例中 Python 應用的核心邏輯比較簡單,你可能一眼就能看出問題,但實際生產環境中的源碼就復雜多了。所以,
          我依舊建議,操作之前別看源碼,避免先入為主,要把它當成一個黑盒來分析。這樣 你可以更好把握住,怎么從系統的資源使用問題出發,分析出瓶頸
          所在的應用,以及瓶頸在應用中大概的位置

          3、測試環境準備

          1、運行目標應用

          ?

          1

          docker run --name=app -p 10000:80 -itd feisky/word-pop

          2、確認應用正常啟動

          ?

          1

          2

          3

          4

          [[email protected] ~]# ps aux | grep app.py

          root      10130  0.0  0.5  95700 23392 pts/0    Ss+  10:29   0:00 python /app.py

          root      10167 30.8  0.7 104924 30372 pts/0    Sl+  10:29   4:32 /usr/local/bin/python /app.py

          root      10256  0.0  0.0 112716  2288 pts/1    S+   10:44   0:00 grep --color=auto app.py

          二、故障現象

          1、發現故障

          1、接下來,在第二個終端中,訪問案例應用的單詞熱度接口

          ?

          1

          2

          3

          4

          5

          6

          [[email protected] ~]# curl http://192.168.118.115:10000

          hello world[[email protected] ~]# curl http://192.168.118.115:10000/popularity/word

          {

            "popularity": 0.0,

            "word": "word"

          }

          稍等一會兒,你會發現,這個接口居然這么長時間都沒響應,究竟是怎么回事呢?我們先回到終端一來分析一下。

          2、我們試試在第一個終端里,隨便執行一個命令,居然也要等好久才能輸出

          ?

          1

          2

          3

          4

          5

          6

          7

          8

          9

          10

          [[email protected] ~]# df

          Filesystem     1K-blocks     Used Available Use% Mounted on

          devtmpfs         1995624        0   1995624   0% /dev

          tmpfs            2007620        0   2007620   0% /dev/shm

          tmpfs            2007620     9336   1998284   1% /run

          tmpfs            2007620        0   2007620   0% /sys/fs/cgroup

          /dev/sda2       50306052 29273120  21032932  59% /

          tmpfs             401524        0    401524   0% /run/user/0

          overlay         50306052 29273120  21032932  59% /var/lib/docker/overlay2/0bc7de96c86ea3d2fe1059ccf2dea175b05a5434cc0a73858b5292b610699530/merged

          shm                65536        0     65536   0% /var/lib/docker/containers/f0b72f14052f48a2a6eaf034d11e2fea77b76250bd87863e50d2f8aeb22c9918/mounts/shm

          2、故障現象

          1、top

          進程部分有一個 python 進程的 CPU 使用率稍微有點達到了 40.4%。雖然 40.1%并不能成為性能瓶頸,不過有點嫌疑——可能跟 iowait 的升高有關

          那這個 PID 號為 10167 的 python 進程,到底是不是我們的案例應用呢?

          2、然后執行下面的 ps 命令,查找案例應用 app.py 的 PID 號:

          ?

          1

          2

          3

          4

          [[email protected] ~]# ps aux | grep app.py

          root      10130  0.0  0.5  95700 23392 pts/0    Ss+  10:29   0:00 python /app.py

          root      10167 30.8  0.7 104924 30372 pts/0    Sl+  10:29   4:32 /usr/local/bin/python /app.py

          root      10256  0.0  0.0 112716  2288 pts/1    S+   10:44   0:00 grep --color=auto app.py

          從 ps 的輸出,你可以看到,這個 CPU 使用率較高的進程,不過先別著急分析 CPU 問題,畢竟 iowait 已經高達92%

          三、分析過程

          1、觀察系統I/O使用情況

          1、案例

          ?

          1

          2

          3

          4

          iostat -d -x 1

          Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util

          loop0            0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00

          sda              0.00   71.00      0.00  32912.00     0.00     0.00   0.00   0.00    0.00 18118.31 241.89     0.00   463.55  13.86  98.40

          2、實際測試

          ?

          1

          2

          3

          4

          5

          6

          7

          8

          9

          10

          11

          12

          13

          14

          [email protected] ~]# iostat -d -x 1

          Linux 5.1.0-1.el7.elrepo.x86_64 (luoahong)  05/30/2019  _x86_64_    (2 CPU)

           

          Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz  aqu-sz  %util

          sda              2.14    834.77     0.01   0.44   23.88   390.85   75.84  85205.18     0.60   0.79  191.95  1123.42    0.00      0.00     0.00   0.00    0.00     0.00   14.57  10.79

           

          Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz  aqu-sz  %util

          sda              0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00   0.00

           

          Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz  aqu-sz  %util

          sda              0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00   0.00

           

          Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz  aqu-sz  %util

          sda              0.00      0.00     0.00   0.00    0.00     0.00  125.00 103592.00     1.00   0.79   39.18   828.74    0.00      0.00     0.00   0.00    0.00     0.00    4.83  14.90

          -d 選項是指顯示出I/O的性能指標;

          -x 選項是指顯示出擴展統計信息(即顯示所有I/O指標)

          1、你可以發現,磁盤 sda 的 I/O 使用率已經達到 98%接近飽和了
          2、而且,寫請求的響應時間高達 18 秒,每秒的寫數據為32MB,雖然寫磁盤碰到了瓶頸
          3、這些I/O請求到底是那些進程導致的呢?

          2、知道了進程PID,具體要怎么查看寫的情況呢?

          ?

          1

          2

          3

          4

          5

          6

          7

          8

          9

          10

          [[email protected] ~]# pidstat -d 1

          Linux 5.1.0-1.el7.elrepo.x86_64 (luoahong)  05/30/2019  _x86_64_    (2 CPU)

           

          11:19:22 AM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command

          11:19:23 AM     0     10167      0.00 124549.02      0.00       0  python

          11:19:23 AM     0     10191      0.00      0.00      0.00     108  kworker/u256:1+flush-8:0

           

          11:19:23 AM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command

          11:19:24 AM     0     10167      0.00 126168.00      0.00       0  python

          11:19:24 AM     0     10191      0.00      0.00      0.00     100  kworker/u256:1+flush-8:0

          走到這一步,你估計覺得,接下來就很簡單了,上一個案例不剛剛學過嗎?無非就是,先用 strace 確認它是不是在寫文件,再用 lsof 找出文件描述符對應的文件即可。

          1、strace查看制定PID調用情況

          ?

          1

          2

          3

          4

          5

          6

          7

          8

          [[email protected] ~]# strace -p 10167

          strace: Process 10167 attached

          select(0, NULL, NULL, NULL, {0, 403619}) = 0 (Timeout)

          ......

          stat("/usr/local/lib/python3.7/stringprep.py", {st_mode=S_IFREG|0644, st_size=12917, ...}) = 0

          stat("/usr/local/lib/python3.7/stringprep.py", {st_mode=S_IFREG|0644, st_size=12917, ...}) = 0

          stat("/usr/local/lib/python3.7/_bootlocale.py", {st_mode=S_IFREG|0644, st_size=1801, ...}) = 0

          stat("/usr/local/lib/python3.7/_bootlocale.py", {st_mode=S_IFREG|0644, st_size=1801, ...}) =

          由于 strace 的輸出比較多,我們可以用 grep ,來過濾一下 write,比如:

          ?

          1

          [[email protected] ~]# strace -p 10167 2>&1 |grep write

          遺憾的是沒有任何輸出

          2、filetop

          它是 bcc 軟件包的一部分,基于 Linux 內核的eBPF(extended Berkeley Packet Filters)機制,主要跟蹤內核中文件的讀寫情況,并輸出線
          程 ID(TID)、讀寫大小、讀寫類型以及文件名稱。

          bcc的安裝方法:https://github.com/iovisor/bcc

          ?

          1

          2

          3

          4

          sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4052245BD4284CDD

          echo "deb https://repo.iovisor.org/apt/$(lsb_release -cs) $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/iovisor.list

          sudo apt-get update

          sudo apt-get install bcc-tools libbcc-examples linux-headers-$(uname -r)

          安裝后,bcc 提供的所有工具,就全部安裝到了/usr/share/bcc/tools 這個目錄中接下來我們就用這個工具,觀察一下文件的讀寫情況。

          ?

          1

          2

          3

          4

          5

          6

          7

          8

          9

          10

          11

          12

          13

          14

          15

          16

          17

          18

          19

          20

          21

          22

          23

          24

          25

          26

          [[email protected] tools]# ./filetop -C

          Tracing... Output every 1 secs. Hit Ctrl-C to end

           

          11:54:58 loadavg: 2.37 1.27 0.54 2/185 9851

           

          TID    COMM             READS  WRITES R_Kb    W_Kb    T FILE

          9850   python           2      0      3662    0       R 995.txt

          9850   python           2      0      3564    0       R 998.txt

          9850   python           2      0      3466    0       R 986.txt

          9850   python           2      0      3466    0       R 994.txt

          9850   python           2      0      3222    0       R 988.txt

          9850   python           2      0      3173    0       R 993.txt

          9850   python           2      0      2929    0       R 992.txt

          9850   python           2      0      2832    0       R 990.txt

          9850   python           2      0      2734    0       R 989.txt

          9850   python           2      0      2490    0       R 997.txt

          9850   python           2      0      2441    0       R 999.txt

          9850   python           2      0      2294    0       R 987.txt

          9850   python           2      0      2246    0       R 996.txt

          9850   python           2      0      2099    0       R 984.txt

          9850   python           2      0      1806    0       R 985.txt

          9850   python           2      0      1660    0       R 991.txt

          9847   filetop          1      0      4       0       R retprobe

          9847   filetop          1      0      4       0       R type

          9847   filetop          2      0      2       0       R loadavg

          9851   sleep            1      0      0       0       R libc-2.17.so

          線程號為 514 的線程,屬于哪個進程呢?

          ?

          1

          2

          3

          [[email protected] tools]# ps -efT|grep 9891

          root       9798   9891   9755 46 11:59 pts/0    00:00:07 /usr/local/bin/python /app.py

          root       9894   9894   9805  0 12:00 pts/1    00:00:00 grep --color=auto 9891

          filetop 只給出了文件名稱,卻沒有文件路徑,還得繼續找啊

          3、opensnoop 

          它同屬于 bcc 軟件包,可以動態跟蹤內核中的 open 系統調用。這樣,我們可以找出這些txt文件的路徑

          ?

          1

          2

          3

          4

          5

          6

          7

          8

          9

          10

          11

          12

          13

          14

          15

          16

          17

          18

          19

          20

          21

          [[email protected] tools]# ./opensnoop

          PID    COMM               FD ERR PATH

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/898.txt

          9921   opensnoop          -1   2 /usr/lib64/python2.7/encodings/ascii.so

          9921   opensnoop          -1   2 /usr/lib64/python2.7/encodings/asciimodule.so

          9921   opensnoop          12   0 /usr/lib64/python2.7/encodings/ascii.py

          9921   opensnoop          13   0 /usr/lib64/python2.7/encodings/ascii.pyc

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/899.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/900.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/901.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/902.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/903.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/904.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/905.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/906.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/907.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/908.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/909.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/910.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/911.txt

          9798   python              6   0 /tmp/9ef81916-828f-11e9-960a-0242ac110002/912.txt

          綜合 filetop 和 opensnoop ,我們就可以進一步分析了。我們可以大膽猜測,案例應用在寫入1000 個 txt 文件后又把這些內容讀到內存中進行處理
          我們來檢查一下,這個目錄中是不是真的有 1000 個文件:

          ?

          1

          2

          3

          [[email protected] tools]# ls /tmp/9ef81916-828f-11e9-960a-0242ac110002 |wc -l

          ls: cannot access /tmp/9ef81916-828f-11e9-960a-0242ac110002: No such file or directory

          0

          操作后卻發現,目錄居然不存在了,怎么回事呢?我們回到 opensnoop 再觀察一會兒

          ?

          1

          2

          3

          4

          5

          6

          7

          8

          9

          10

          11

          12

          13

          [[email protected] tools]# ./opensnoop

          PID    COMM               FD ERR PATH

          9798   python              6   0 /tmp/d94f7bec-829c-11e9-960a-0242ac110002/351.txt

          10589  opensnoop          -1   2 /usr/lib64/python2.7/encodings/ascii.so

          10589  opensnoop          -1   2 /usr/lib64/python2.7/encodings/asciimodule.so

          10589  opensnoop          12   0 /usr/lib64/python2.7/encodings/ascii.py

          10589  opensnoop          13   0 /usr/lib64/python2.7/encodings/ascii.pyc

          9798   python              6   0 /tmp/d94f7bec-829c-11e9-960a-0242ac110002/352.txt

          9798   python              6   0 /tmp/d94f7bec-829c-11e9-960a-0242ac110002/353.txt

          9798   python              6   0 /tmp/d94f7bec-829c-11e9-960a-0242ac110002/354.txt

          9798   python              6   0 /tmp/d94f7bec-829c-11e9-960a-0242ac110002/355.txt

          9798   python              6   0 /tmp/d94f7bec-829c-11e9-960a-0242ac110002/356.txt

          9798   python              6   0 /tmp/d94f7bec-829c-11e9-960a-0242ac110002/357.txt

          原來,這時的路徑已經變成了另一個目錄,這說明,這些目錄都是應用程序動態生成的,用完就刪了。

          結合前面的所有分析,我們基本可以判斷,案例應用會動態生成一批文件,用來臨時存儲數據,用完就會刪除它們。但不幸的是,正是這些文件讀寫,引發了 I/O 的性能瓶頸,

          導致整個處理過程非常慢

          4、確認猜想(查看源代碼)

          ?

          1

          2

          3

          4

          5

          6

          7

          8

          9

          10

          11

          12

          13

          14

          15

          16

          17

          18

          19

          20

          21

          22

          23

          24

          25

          26

          27

          28

          29

          30

          31

          @app.route("/popularity/<word>")

          def word_popularity(word):

            dir_path = '/tmp/{}'.format(uuid.uuid1())

            count = 0

            sample_size = 1000

              

            def save_to_file(file_name, content):

              with open(file_name, 'w') as f:

              f.write(content)

           

            try:

              # initial directory firstly

              os.mkdir(dir_path)

           

              # save article to files

              for i in range(sample_size):

                  file_name = '{}/{}.txt'.format(dir_path, i)

                  article = generate_article()

                  save_to_file(file_name, article)

           

              # count word popularity

              for root, dirs, files in os.walk(dir_path):

                  for file_name in files:

                      with open('{}/{}'.format(dir_path, file_name)) as f:

                          if validate(word, f.read()):

                              count += 1

              finally:

                  # clean files

                  shutil.rmtree(dir_path, ignore_errors=True)

           

              return jsonify({'popularity': count / sample_size * 100, 'word': word})

          四、解決方案

          1、問題總結

          源碼中可以看到,這個案例應用

          1、在每個請求的處理過程中毛都會生成一批臨時文件。
          2、然后讀入內存處理,
          3、最后把整個目錄刪除掉

          這是一種常見的利用磁盤空間處理大量數據技巧,不過,本次案例中I/O請求太重。導致磁盤I/O利用率過高

          2、算法優化

          要解決這一點其實就是算法優化問題,比如在內存充足時,就可以把所有的數據存放到內存中處理,這樣就避免I/O的性能問題

          你可以檢驗一下,在中斷二中分別訪問:http://192.168.0.10:10000/popularity/word和http://192.168.0.10:10000/popular/word對比前后的效果

          http://192.168.0.10:10000/popularity/word

          ?

          1

          2

          3

          4

          5

          6

          7

          8

          time curl http://192.168.0.10:10000/popularity/word

          {

            "popularity": 0.0,

            "word": "word"

          }

          real    2m43.172s

          user    0m0.004s

          sys    0m0.007s

          http://192.168.0.10:10000/popular/word

          ?

          1

          2

          3

          4

          5

          6

          7

          8

          9

          time curl http://192.168.0.10:10000/popular/word

          {

            "popularity": 0.0,

            "word": "word"

          }

           

          real    0m8.810s

          user    0m0.010s

          sys    0m0.000s

          新的接口只要 8 秒就可以返回,明顯比一開始的 3 分鐘好很多

          當然,這只是優化的第一步,并且方法不算完善,還可以做進一步的優化,

          不過,在實際系統中,我們大都是類似的做法,先用簡單的方法,盡早解決線上問題,然后在繼續思考更好的優化方法

          五、故障小結

          今天,我們分析了一個響應過慢的單詞熱度案例。

          首先,我們用 top、iostat,分析了系統的 CPU 和磁盤使用情況,我們發現了磁盤I/O 瓶頸,也知道了這個瓶頸是案例應用導致的。

          接著,我們試著照搬上一節案例的方法,用 strace 來觀察進程的系統調用,不過這次很不走運,沒找到任何 write 系統調用。

          于是,我們又用了新的工具,借助動態追蹤工具包 bcc 中的 filetop 和 opensnoop ,找出了案例應用的問題,發現這個根源是大量讀寫臨時文件。

          找出問題后,優化方法就相對比較簡單了。如果內存充足時,最簡單的方法,就是把數據都放在速度更快的內存中,這樣就沒有磁盤 I/O 的瓶頸了。

          當然,再進一步,你可以還可以利用 Trie 樹等各種算法,進一步優化單詞處理的效率。


           

          作者:羅阿紅 出處:http://www.cnblogs.com/luoahong/ 本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接。

          版權聲明:本文為博主原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處鏈接和本聲明。
          本文鏈接:https://blog.csdn.net/jj1130050965/article/details/109777973

          智能推薦

          暑假第二十七測

          今天是我調代碼最久的y一天 題解: 第一題: check的時候記錄c字符從左區間向右第一次出現cmin, 和最后一次出現cmax; 如果這個區間合法,就有cmax(c -1) < cmin(c); 這道題的細節很多,比如其中一個字符沒有出現怎么辦(數據中每組都有這種情況,還有邊界的取舍); 我調了一下午,最后又是請zjj同學幫我看的, 結果多組數據初值沒有搞好 View Code  ...

          概率論與數理統計學習筆記——第二十七講——隨機變量的數學期望

            1. 隨機變量的數字特征   2. 數學期望的引例——射手技術比較   3. 數學期望的定義   4. “期望”名稱的起源——分賭本問題   5. 0-1分布的期望即為其參數p   6. 泊松分布的期望即為其參數λ   7. 正態分布的期望...

          第二十七講 常用類——StringBuffer與StringBuilder

          StringBuffer 概述 我們如果對字符串進行拼接操作的話,每次拼接時,都會構建一個新的String對象,既耗時又浪費空間。而StringBuffer就可以解決這個問題。StringBuffer是一個線程安全的可變字符序列(即字符串緩沖區),它是一個容器。 特點 長度可以變化; 可以對內容通過指定的方法進行修改; 容器對象一般都會具備對容器中的元素進行操作的功能,比如增刪改查; 緩沖區中可以...

          Linux性能優化實戰學習筆記:第四十七講

          Linux性能優化實戰學習筆記:第四十七講 一、上節回顧 上一節,我們梳理了,應用程序容器化后性能下降的分析方法。一起先簡單回顧下。 容器利用 Linux 內核提供的命名空間技術,將不同應用程序的運行隔離起來,并用統一的鏡像,來管理應用程序的依賴環境。這為應用程序的管理和維護,帶來了極大的便捷性,并進一步催生 了微服務、云原生等新一代技術架構。 不過,雖說有很多優勢,但容器化也會對應用程序的性能帶...

          Linux性能優化實戰學習筆記:第五十七講

          Linux性能優化實戰學習筆記:第五十七講 一、上節回顧 上一節,我帶你一起梳理了常見的性能優化思路,先簡單回顧一下。我們可以從系統和應用程序兩個角度,來進行性能優化。 從系統的角度來說,主要是對 CPU、內存、網絡、磁盤 I/O 以及內核軟件資源等進行優化。 而從應用程序的角度來說,主要是簡化代碼、降低 CPU 使用、減少網絡請求和磁盤 I/O,并借助緩存、異步處理、多進程和多線程等,提高應用程...

          猜你喜歡

          python學習第二十七天(HTML之表單標簽)

          form表單標簽 表單用于向服務器傳輸數據。 表單能夠包含 input 元素,比如文本字段、復選框、單選框、提交按鈕等等。 表單還可以包含textarea、select、fieldset和 label 元素。 表單屬性 HTML 表單用于接收不同類型的用戶輸入,用戶提交表單時向服務器傳輸數據,從而實現用戶與Web服務器的交互。表單標簽, 要提交的所有內容都應該在該標簽中. 1、action: 表單...

          Python學習的第二十七天(random模塊與網絡編程)

          random模塊 導入 隨機整數 包括最大值,不可加步長 不包括最大值,但可以給步長 隨機選擇一個返回 隨機取多個返回 隨機取多個,返回結果是列表 打亂順序 用于洗牌,會改變列表自身數據 作業生成驗證碼 隨機生成八位數驗證碼 提示 利用一下ascii chr(ascii碼值) 可得到 對應的字符 目標,需要獲得一個八位的由數字和字母組成的隨機驗證碼 0-9 大寫的A-Z 65-90 小寫的a-z ...

          通過pytorch建立神經網絡模型 分析遺傳基因數據

          DNA雙螺旋(已對齊)合并神經網絡(黃色) 我最近進行了有關基因序列的研究工作。我想到的主要問題是:“哪一種最簡單的神經網絡能與遺傳數據最匹配”。經過大量文獻回顧,我發現與該主題相關的最接地氣卻非常有趣的工作是在Yoshua Bengio 教授的實驗室中進行的。這篇論文的題目是:“飲食網絡:脂肪基因組學的瘦參數”,它的主要目標是將基因序列劃分為26個...

          在cmd下運行javac報告javac不是內部或外部命令,但是運行java、java-version正常

          首先在環境變量配置都沒有問題的情況下還出現了“javac不是內部或外部命令”的情況下,是因為安裝的jdk的bin目錄下丟失了ava.exe文件。 那么它到底丟哪去了呢?回答:被覆蓋了。 當下載jdk并安裝的時候,你會發現安裝是要分兩次進行的,過程要選兩次安裝路徑。 第一次提示安裝的是jdk,第二次安裝的是jre,兩個安裝路徑不能放在同一個路徑里,要分別安裝到不同的路徑。 最...

          Hyper-V 3.0功能部署PART 5:秒級實時遷移

          在前面的一些文章中我們已經逐漸的看到Hyper-V 3.0的強大之處,今天我們將繼續來部署配置Hyper-V 3.0的功能。在前面的文章中我們已經將虛擬機的文件或者說虛擬機的虛擬磁盤放在了SMB共享存儲中,實現了基本的虛擬機磁盤放SMB共享存儲服務器-虛擬機運行放Hyper-V主機服務器的局面。那么在此基礎上,我們就可以實現秒級的虛擬機實時移動功能了。 要實現秒級的移動功能。我...

          贊助商廣告

          相關文章

          熱門文章

          推薦文章

          相關標簽

          亚洲中文字幕A∨在线

          <noframes id="vddlx"><form id="vddlx"><nobr id="vddlx"></nobr></form>

            <noframes id="vddlx">
            <listing id="vddlx"><nobr id="vddlx"><meter id="vddlx"></meter></nobr></listing>
            <form id="vddlx"><th id="vddlx"><progress id="vddlx"></progress></th></form><em id="vddlx"></em>

              
              

              <listing id="vddlx"><listing id="vddlx"><menuitem id="vddlx"></menuitem></listing></listing>

                <span id="vddlx"></span>