រូបមន្តសម្រាប់សំណួរ SQL ឈឺ

ប៉ុន្មានខែមុន យើង​បាន​ប្រកាស ពន្យល់.tensor.ru - សាធារណៈ សេវាកម្មសម្រាប់ញែក និងមើលឃើញផែនការសំណួរ ទៅ PostgreSQL ។

អ្នកបានប្រើវាច្រើនជាង 6000 ដងហើយ ប៉ុន្តែមុខងារងាយស្រួលមួយដែលប្រហែលជាមិនមាននរណាកត់សម្គាល់នោះគឺ តម្រុយរចនាសម្ព័ន្ធដែលមើលទៅដូចនេះ៖

ស្តាប់ពួកគេ ហើយសំណើរបស់អ្នកនឹង "ក្លាយជារលូន និងស្ងប់ស្ងាត់"។ 🙂

ប៉ុន្តែធ្ងន់ធ្ងរ ស្ថានភាពជាច្រើនដែលធ្វើឱ្យសំណើយឺតយ៉ាវ និងស្រេកឃ្លានធនធាន មានលក្ខណៈធម្មតា ហើយអាចត្រូវបានទទួលស្គាល់ដោយរចនាសម្ព័ន្ធ និងទិន្នន័យនៃផែនការ.

ក្នុងករណីនេះ អ្នកអភិវឌ្ឍន៍ម្នាក់ៗមិនចាំបាច់ស្វែងរកជម្រើសបង្កើនប្រសិទ្ធភាពដោយខ្លួនឯងទេ ដោយពឹងផ្អែកតែលើបទពិសោធន៍របស់គាត់ - យើងអាចប្រាប់គាត់ពីអ្វីដែលកំពុងកើតឡើងនៅទីនេះ អ្វីដែលអាចជាហេតុផល និង របៀប​រក​ដំណោះស្រាយ. នោះហើយជាអ្វីដែលយើងបានធ្វើ។

សូមពិនិត្យមើលឱ្យកាន់តែច្បាស់អំពីករណីទាំងនេះ - របៀបដែលពួកវាត្រូវបានកំណត់ និងអនុសាសន៍អ្វីខ្លះដែលពួកគេនាំទៅរក។

ដើម្បីជ្រមុជខ្លួនអ្នកឱ្យកាន់តែប្រសើរឡើងនៅក្នុងប្រធានបទដំបូងអ្នកអាចស្តាប់ប្លុកដែលត្រូវគ្នាពី របាយការណ៍របស់ខ្ញុំនៅ PGConf.Russia 2020ហើយបន្ទាប់មកបន្តទៅការវិភាគលម្អិតនៃឧទាហរណ៍នីមួយៗ៖

# 1: លិបិក្រម "ការតម្រៀប"

នៅពេលដែលកើតឡើង

បង្ហាញវិក្កយបត្រចុងក្រោយបំផុតសម្រាប់អតិថិជន "LLC Kolokolchik" ។

របៀបកំណត់អត្តសញ្ញាណ

-> Limit
   -> Sort
      -> Index [Only] Scan [Backward] | Bitmap Heap Scan

អនុសាសន៍

សន្ទស្សន៍ដែលបានប្រើ ពង្រីកជាមួយវាលតម្រៀប.

ឧទាហរណ៍:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk  -- 100K "фактов"
, (random() * 1000)::integer fk_cli; -- 1K разных внешних ключей

CREATE INDEX ON tbl(fk_cli); -- индекс для foreign key

SELECT
  *
FROM
  tbl
WHERE
  fk_cli = 1 -- отбор по конкретной связи
ORDER BY
  pk DESC -- хотим всего одну "последнюю" запись
LIMIT 1;

[សូមមើលពន្យល់.tensor.ru]

អ្នកអាចកត់សម្គាល់ភ្លាមៗថាកំណត់ត្រាច្រើនជាង 100 ត្រូវបានដកចេញពីលិបិក្រម ដែលបន្ទាប់មកត្រូវបានតម្រៀបទាំងអស់ ហើយបន្ទាប់មកនៅសល់តែមួយប៉ុណ្ណោះ។

ការកែតម្រូវ៖

DROP INDEX tbl_fk_cli_idx;
CREATE INDEX ON tbl(fk_cli, pk DESC); -- добавили ключ сортировки

[សូមមើលពន្យល់.tensor.ru]

សូម្បីតែនៅលើគំរូដើមបែបនេះ - លឿនជាង 8.5 ដង និងអានតិចជាង 33 ដង. "ការពិត" កាន់តែច្រើនដែលអ្នកមានសម្រាប់តម្លៃនីមួយៗ ឥទ្ធិពលកាន់តែច្បាស់ fk.

ខ្ញុំកត់សម្គាល់ថាសន្ទស្សន៍បែបនេះនឹងដំណើរការជា "បុព្វបទ" សន្ទស្សន៍មិនអាក្រក់ជាងពីមុនសម្រាប់សំណួរផ្សេងទៀតជាមួយ fkដែលជាកន្លែងដែលតម្រៀបតាម pk វាមិនមាន និងមិនមាន (អ្នកអាចអានបន្ថែមអំពីរឿងនេះ នៅក្នុងអត្ថបទរបស់ខ្ញុំអំពីការស្វែងរកលិបិក្រមដែលមិនមានប្រសិទ្ធភាព) រួមទាំងវានឹងផ្តល់ធម្មតា។ ការគាំទ្រគន្លឹះបរទេសច្បាស់លាស់ នៅលើវាលនេះ។

# 2: ចំនុចប្រសព្វសន្ទស្សន៍ (BitmapAnd)

នៅពេលដែលកើតឡើង

បង្ហាញកិច្ចព្រមព្រៀងទាំងអស់សម្រាប់អតិថិជន "LLC Kolokolchik" ដែលបានបញ្ចប់ក្នុងនាម "NAO Buttercup" ។

របៀបកំណត់អត្តសញ្ញាណ

-> BitmapAnd
   -> Bitmap Index Scan
   -> Bitmap Index Scan

អនុសាសន៍

បង្កើត សន្ទស្សន៍សមាសធាតុ តាម​វាល​ទាំង​ពី​ដើម​ឬ​ពង្រីក​មួយ​ក្នុង​ចំណោម​ដែល​មាន​ស្រាប់​ជាមួយ​វាល​ពី​ទីពីរ។

ឧទាហរណ៍:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk      -- 100K "фактов"
, (random() *  100)::integer fk_org  -- 100 разных внешних ключей
, (random() * 1000)::integer fk_cli; -- 1K разных внешних ключей

CREATE INDEX ON tbl(fk_org); -- индекс для foreign key
CREATE INDEX ON tbl(fk_cli); -- индекс для foreign key

SELECT
  *
FROM
  tbl
WHERE
  (fk_org, fk_cli) = (1, 999); -- отбор по конкретной паре

[សូមមើលពន្យល់.tensor.ru]

ការកែតម្រូវ៖

DROP INDEX tbl_fk_org_idx;
CREATE INDEX ON tbl(fk_org, fk_cli);

[សូមមើលពន្យល់.tensor.ru]

ការទូទាត់នៅទីនេះគឺតូចជាង ដោយសារ Bitmap Heap Scan មានប្រសិទ្ធភាពណាស់ដោយខ្លួនឯង។ ប៉ុន្តែយ៉ាងណាក៏ដោយ លឿនជាង 7 ដង និងអានតិចជាង 2.5 ដង.

# 3: បញ្ចូលសន្ទស្សន៍ (BitmapOr)

នៅពេលដែលកើតឡើង

បង្ហាញ "ពួកយើង" ដែលចាស់ជាងគេចំនួន 20 នាក់ដំបូង ឬសំណើដែលមិនទាន់បានចាត់តាំងសម្រាប់ដំណើរការ ដោយមានអាទិភាពរបស់អ្នក។

របៀបកំណត់អត្តសញ្ញាណ

-> BitmapOr
   -> Bitmap Index Scan
   -> Bitmap Index Scan

អនុសាសន៍

Использовать សហភាព [ទាំងអស់] ដើម្បីបញ្ចូលគ្នានូវសំណួររងសម្រាប់ OR-blocks នៃលក្ខខណ្ឌនីមួយៗ។

ឧទាហរណ៍:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk  -- 100K "фактов"
, CASE
    WHEN random() < 1::real/16 THEN NULL -- с вероятностью 1:16 запись "ничья"
    ELSE (random() * 100)::integer -- 100 разных внешних ключей
  END fk_own;

CREATE INDEX ON tbl(fk_own, pk); -- индекс с "вроде как подходящей" сортировкой

SELECT
  *
FROM
  tbl
WHERE
  fk_own = 1 OR -- свои
  fk_own IS NULL -- ... или "ничьи"
ORDER BY
  pk
, (fk_own = 1) DESC -- сначала "свои"
LIMIT 20;

[សូមមើលពន្យល់.tensor.ru]

ការកែតម្រូវ៖

(
  SELECT
    *
  FROM
    tbl
  WHERE
    fk_own = 1 -- сначала "свои" 20
  ORDER BY
    pk
  LIMIT 20
)
UNION ALL
(
  SELECT
    *
  FROM
    tbl
  WHERE
    fk_own IS NULL -- потом "ничьи" 20
  ORDER BY
    pk
  LIMIT 20
)
LIMIT 20; -- но всего - 20, больше и не надо

[សូមមើលពន្យល់.tensor.ru]

យើងបានទាញយកប្រយោជន៍ពីការពិតដែលថាកំណត់ត្រាដែលទាមទារទាំង 20 ត្រូវបានទទួលភ្លាមៗនៅក្នុងប្លុកទីមួយ ដូច្នេះទីពីរជាមួយនឹង Bitmap Heap Scan ដែលមានតម្លៃថ្លៃជាង មិនត្រូវបានប្រតិបត្តិសូម្បីតែ - នៅទីបញ្ចប់ លឿនជាង 22 ដង អានតិចជាង 44 ដង!

រឿងលម្អិតបន្ថែមទៀតអំពីវិធីសាស្ត្របង្កើនប្រសិទ្ធភាពនេះ។ ដោយប្រើឧទាហរណ៍ជាក់លាក់ អាចត្រូវបានអាននៅក្នុងអត្ថបទ PostgreSQL Antipatterns៖ ការចូលរួម និង ORs ដែលបង្កគ្រោះថ្នាក់ и PostgreSQL Antipatterns៖ រឿងរ៉ាវនៃការចម្រាញ់ឡើងវិញនៃការស្វែងរកតាមឈ្មោះ ឬ “ការបង្កើនប្រសិទ្ធភាពទៅវិញទៅមក”.

កំណែទូទៅ ការជ្រើសរើសតាមលំដាប់ដោយផ្អែកលើគ្រាប់ចុចជាច្រើន។ (និងមិនត្រឹមតែគូ const/NULL) ត្រូវបានពិភាក្សានៅក្នុងអត្ថបទ SQL HowTo: សរសេរ while-loop ដោយផ្ទាល់នៅក្នុងសំណួរ ឬ "Elementary three-way".

#៤៖ យើងអានរឿងដែលមិនចាំបាច់ច្រើន។

នៅពេលដែលកើតឡើង

តាមក្បួនវាកើតឡើងនៅពេលអ្នកចង់ "ភ្ជាប់តម្រងផ្សេងទៀត" ទៅនឹងសំណើដែលមានស្រាប់។

"ហើយអ្នកមិនមានដូចគ្នាទេ ប៉ុន្តែ ជាមួយនឹងប៊ូតុងគុជខ្យង? ខ្សែភាពយន្ត "ដៃពេជ្រ"

ឧទាហរណ៍ ការកែប្រែកិច្ចការខាងលើ បង្ហាញសំណើ "សំខាន់" ចាស់បំផុតចំនួន 20 ដំបូងសម្រាប់ដំណើរការ ដោយមិនគិតពីគោលបំណងរបស់ពួកគេ។

របៀបកំណត់អត្តសញ្ញាណ

-> Seq Scan | Bitmap Heap Scan | Index [Only] Scan [Backward]
   && 5 × rows < RRbF -- отфильтровано >80% прочитанного
   && loops × RRbF > 100 -- и при этом больше 100 записей суммарно

អនុសាសន៍

បង្កើត [បន្ថែម] ឯកទេស សន្ទស្សន៍ជាមួយលក្ខខណ្ឌ WHERE ឬរួមបញ្ចូលវាលបន្ថែមនៅក្នុងលិបិក្រម។

ប្រសិនបើលក្ខខណ្ឌតម្រងគឺ "ឋិតិវន្ត" សម្រាប់គោលបំណងរបស់អ្នក - នោះគឺ មិនមានន័យថាការពង្រីកទេ។ បញ្ជីតម្លៃនាពេលអនាគត - វាជាការប្រសើរក្នុងការប្រើសន្ទស្សន៍ WHERE ។ ស្ថានភាព boolean/enum ជាច្រើនសមនឹងល្អនៅក្នុងប្រភេទនេះ។

ប្រសិនបើលក្ខខណ្ឌតម្រង អាចទទួលយកអត្ថន័យផ្សេងគ្នាបន្ទាប់មក វាជាការប្រសើរក្នុងការពង្រីកលិបិក្រមជាមួយវាលទាំងនេះ - ដូចនៅក្នុងស្ថានភាពជាមួយ BitmapAnd ខាងលើ។

ឧទាហរណ៍:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk -- 100K "фактов"
, CASE
    WHEN random() < 1::real/16 THEN NULL
    ELSE (random() * 100)::integer -- 100 разных внешних ключей
  END fk_own
, (random() < 1::real/50) critical; -- 1:50, что заявка "критичная"

CREATE INDEX ON tbl(pk);
CREATE INDEX ON tbl(fk_own, pk);

SELECT
  *
FROM
  tbl
WHERE
  critical
ORDER BY
  pk
LIMIT 20;

[សូមមើលពន្យល់.tensor.ru]

ការកែតម្រូវ៖

CREATE INDEX ON tbl(pk)
  WHERE critical; -- добавили "статичное" условие фильтрации

[សូមមើលពន្យល់.tensor.ru]

ដូចដែលអ្នកបានឃើញ ការត្រងបានបាត់ទាំងស្រុងពីផែនការ ហើយសំណើបានក្លាយទៅជា លឿនជាង 5 ដង.

លេខ ៥៖ តារាងតូច

នៅពេលដែលកើតឡើង

ការប៉ុនប៉ងជាច្រើនដើម្បីបង្កើតជួរដំណើរការកិច្ចការផ្ទាល់ខ្លួនរបស់អ្នក នៅពេលដែលចំនួននៃការធ្វើបច្ចុប្បន្នភាព/ការលុបកំណត់ត្រាជាច្រើននៅលើតារាងនាំឱ្យមានស្ថានភាពនៃកំណត់ត្រា "ស្លាប់" មួយចំនួនធំ។

របៀបកំណត់អត្តសញ្ញាណ

-> Seq Scan | Bitmap Heap Scan | Index [Only] Scan [Backward]
   && loops × (rows + RRbF) < (shared hit + shared read) × 8
      -- прочитано больше 1KB на каждую запись
   && shared hit + shared read > 64

អនុសាសន៍

អនុវត្តដោយដៃជាទៀងទាត់ VACUUM [ពេញ] ឬទទួលបានការបណ្តុះបណ្តាលឱ្យបានញឹកញាប់គ្រប់គ្រាន់ ស្វ័យប្រវត្តិ ដោយការលៃតម្រូវប៉ារ៉ាម៉ែត្ររបស់វា រួមទាំង សម្រាប់តារាងជាក់លាក់.

ក្នុងករណីភាគច្រើន បញ្ហាបែបនេះត្រូវបានបង្កឡើងដោយសមាសភាពសំណួរមិនល្អ នៅពេលហៅចេញពីតក្កវិជ្ជាអាជីវកម្មដូចអ្វីដែលបានពិភាក្សា PostgreSQL Antipatterns: ប្រយុទ្ធប្រឆាំងនឹងហ្វូងមនុស្សនៃ "ស្លាប់".

ប៉ុន្តែអ្នកត្រូវយល់ថា សូម្បីតែ VACUUM FULL ក៏អាចមិនតែងតែជួយបានដែរ។ សម្រាប់ករណីបែបនេះវាមានតម្លៃស្គាល់ខ្លួនអ្នកជាមួយនឹងក្បួនដោះស្រាយពីអត្ថបទ DBA: នៅពេលដែល VACUUM បរាជ័យ យើងសម្អាតតារាងដោយដៃ.

# 6: ការអានពី "កណ្តាល" នៃសន្ទស្សន៍

នៅពេលដែលកើតឡើង

វាហាក់បីដូចជាយើងបានអានបន្តិចបន្តួច ហើយអ្វីៗទាំងអស់ត្រូវបានធ្វើលិបិក្រម ហើយយើងមិនបានត្រងអ្នកណាម្នាក់លើសនោះទេ ប៉ុន្តែយើងនៅតែអានទំព័រច្រើនជាងអ្វីដែលយើងចង់បាន។

របៀបកំណត់អត្តសញ្ញាណ

-> Index [Only] Scan [Backward]
   && loops × (rows + RRbF) < (shared hit + shared read) × 8
      -- прочитано больше 1KB на каждую запись
   && shared hit + shared read > 64

អនុសាសន៍

សូមក្រឡេកមើលយ៉ាងដិតដល់នូវរចនាសម្ព័ន្ធនៃលិបិក្រមដែលបានប្រើ និងវាលសំខាន់ៗដែលបានបញ្ជាក់នៅក្នុងសំណួរ - ទំនងបំផុត។ ផ្នែកនៃសន្ទស្សន៍មិនត្រូវបានកំណត់ទេ។. ភាគច្រើនអ្នកនឹងត្រូវបង្កើតលិបិក្រមស្រដៀងគ្នា ប៉ុន្តែដោយគ្មានវាលបុព្វបទ ឬ រៀនរំលឹកគុណតម្លៃរបស់ពួកគេ។.

ឧទាហរណ៍:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk      -- 100K "фактов"
, (random() *  100)::integer fk_org  -- 100 разных внешних ключей
, (random() * 1000)::integer fk_cli; -- 1K разных внешних ключей

CREATE INDEX ON tbl(fk_org, fk_cli); -- все почти как в #2
-- только вот отдельный индекс по fk_cli мы уже посчитали лишним и удалили

SELECT
  *
FROM
  tbl
WHERE
  fk_cli = 999 -- а fk_org не задано, хотя стоит в индексе раньше
LIMIT 20;

[សូមមើលពន្យល់.tensor.ru]

អ្វីគ្រប់យ៉ាងហាក់ដូចជាល្អ ទោះបីជាយោងទៅតាមសន្ទស្សន៍ក៏ដោយ ប៉ុន្តែវាគួរឱ្យសង្ស័យ - សម្រាប់កំណត់ត្រានីមួយៗនៃ 20 ដែលបានអាន យើងត្រូវដកទិន្នន័យ 4 ទំព័រ 32KB ក្នុងមួយកំណត់ត្រា - តើវាមិនដិតទេ? និងឈ្មោះសន្ទស្សន៍ tbl_fk_org_fk_cli_idx បំផុសគំនិត។

ការកែតម្រូវ៖

CREATE INDEX ON tbl(fk_cli);

[សូមមើលពន្យល់.tensor.ru]

ភ្លាមៗ - លឿនជាងមុន 10 ដង និងអានតិចជាង 4 ដង!

ឧទាហរណ៍ផ្សេងទៀតនៃស្ថានភាពនៃការប្រើប្រាស់លិបិក្រមដែលមិនមានប្រសិទ្ធភាពអាចត្រូវបានគេមើលឃើញនៅក្នុងអត្ថបទ DBA: ស្វែងរកលិបិក្រមដែលគ្មានប្រយោជន៍.

លេខ ៧៖ CTE × CTE

នៅពេលដែលកើតឡើង

តាមការស្នើសុំ ទទួលបានពិន្ទុ "ខ្លាញ់" CTE ពីតុផ្សេងគ្នា ហើយបន្ទាប់មកសម្រេចចិត្តធ្វើវារវាងពួកគេ។ JOIN.

ករណីនេះគឺពាក់ព័ន្ធសម្រាប់កំណែខាងក្រោម v12 ឬសំណើជាមួយ WITH MATERIALIZED.

របៀបកំណត់អត្តសញ្ញាណ

-> CTE Scan
   && loops > 10
   && loops × (rows + RRbF) > 10000
      -- слишком большое декартово произведение CTE

អនុសាសន៍

វិភាគដោយប្រុងប្រយ័ត្ននូវសំណើ - និង តើ CTEs ត្រូវការនៅទីនេះទេ?? បើបាទ អញ្ចឹង អនុវត្ត "វចនានុក្រម" នៅក្នុង hstore/json នេះបើយោងតាមគំរូដែលបានពិពណ៌នានៅក្នុង PostgreSQL Antipatterns៖ តោះចុច JOIN ធ្ងន់ៗជាមួយវចនានុក្រម.

លេខ ៨៖ ប្តូរទៅឌីស (ពុម្ពសរសេរ)

នៅពេលដែលកើតឡើង

ដំណើរការតែមួយដង (ការតម្រៀប ឬការធ្វើប្លែកពីគេ) នៃកំណត់ត្រាមួយចំនួនធំមិនសមនឹងអង្គចងចាំដែលបានបម្រុងទុកសម្រាប់ការនេះទេ។

របៀបកំណត់អត្តសញ្ញាណ

-> *
   && temp written > 0

អនុសាសន៍

ប្រសិនបើបរិមាណអង្គចងចាំដែលប្រើដោយប្រតិបត្តិការមិនលើសពីតម្លៃដែលបានបញ្ជាក់នៃប៉ារ៉ាម៉ែត្រ work_memវាគឺមានតំលៃកែតម្រូវវា។ អ្នកអាចភ្លាមៗនៅក្នុងការកំណត់សម្រាប់មនុស្សគ្រប់គ្នា ឬអ្នកអាចឆ្លងកាត់បាន។ SET [LOCAL] សម្រាប់សំណើ/ប្រតិបត្តិការជាក់លាក់។

ឧទាហរណ៍:

SHOW work_mem;
-- "16MB"

SELECT
  random()
FROM
  generate_series(1, 1000000)
ORDER BY
  1;

[សូមមើលពន្យល់.tensor.ru]

ការកែតម្រូវ៖

SET work_mem = '128MB'; -- перед выполнением запроса

[សូមមើលពន្យល់.tensor.ru]

សម្រាប់ហេតុផលជាក់ស្តែង ប្រសិនបើប្រើតែអង្គចងចាំប៉ុណ្ណោះ ហើយមិនមែនថាសទេ នោះសំណួរនឹងត្រូវបានប្រតិបត្តិលឿនជាងមុន។ ក្នុងពេលជាមួយគ្នានេះផ្នែកមួយនៃបន្ទុកពី HDD ក៏ត្រូវបានដកចេញផងដែរ។

ប៉ុន្តែអ្នកត្រូវយល់ថា អ្នកនឹងមិនអាចបែងចែកការចងចាំបានច្រើន និងច្រើននោះទេ - វានឹងមិនគ្រប់គ្រាន់សម្រាប់មនុស្សគ្រប់គ្នានោះទេ។

លេខ ៩៖ ស្ថិតិមិនពាក់ព័ន្ធ

នៅពេលដែលកើតឡើង

ពួកគេបានចាក់ច្រើនចូលទៅក្នុងមូលដ្ឋានទិន្នន័យក្នុងពេលតែមួយ ប៉ុន្តែមិនមានពេលដើម្បីជំរុញវាចេញទេ។ ANALYZE.

របៀបកំណត់អត្តសញ្ញាណ

-> Seq Scan | Bitmap Heap Scan | Index [Only] Scan [Backward]
   && ratio >> 10

អនុសាសន៍

អនុវត្តវាចេញ ANALYZE.

ស្ថានភាពនេះត្រូវបានពិពណ៌នាលម្អិតបន្ថែមទៀតនៅក្នុង PostgreSQL Antipatterns: ស្ថិតិគឺជាអ្វីគ្រប់យ៉ាង.

លេខ ១០៖ "មានអ្វីមួយខុសប្រក្រតី"

នៅពេលដែលកើតឡើង

មានការរង់ចាំសម្រាប់ការចាក់សោរដែលធ្វើឡើងដោយសំណើប្រកួតប្រជែង ឬមានធនធានផ្នែករឹង CPU/hypervisor មិនគ្រប់គ្រាន់។

របៀបកំណត់អត្តសញ្ញាណ

-> *
   && (shared hit / 8K) + (shared read / 1K) < time / 1000
      -- RAM hit = 64MB/s, HDD read = 8MB/s
   && time > 100ms -- читали мало, но слишком долго

អនុសាសន៍

ប្រើខាងក្រៅ ប្រព័ន្ធត្រួតពិនិត្យ ម៉ាស៊ីនមេសម្រាប់ការទប់ស្កាត់ ឬការប្រើប្រាស់ធនធានមិនប្រក្រតី។ យើងបាននិយាយរួចហើយអំពីកំណែរបស់យើងនៃការរៀបចំដំណើរការនេះសម្រាប់ម៉ាស៊ីនមេរាប់រយ នៅទីនេះ и នៅទីនេះ.

ប្រភព: www.habr.com