ฉันตรวจสอบบันทึกที่ช้าและฉันได้รับเพียง 4 ข้อความค้นหาใน 2 ชั่วโมง และทั้งหมดคล้ายกับสิ่งนี้:
"เลือก HEX(uhash) AS uhash, vehid, IF(deleted = 0 AND follow_price_drop = 1, 1, 0) AS follow_price_drop, อีเมล, ลบแล้ว
จาก wp_ product_favorite_count เป็น cfc
เข้าร่วมภายใน wp_ product_favorite_user เป็น cfu บน cfc product_favorite_user_uhash = cfu.uhash
WHERE cfc.updated > '2021-09-23 12:49:02' หรือ cfu.updated > '2021-09-23 12:49:02'"
ฉันตรวจสอบด้านบนและ htop และมักจะได้รับการใช้งาน 100 cpu บนแกนประมวลผลทั้ง 6 แกน
การใช้งาน CPU ส่วนใหญ่มาจาก mysqld ดังนั้นฉันจึงบันทึก db:
iostat -xm 5 3 ให้ฉัน:
avg-cpu: %user %nice %system %iowait %steal %ไม่ได้ใช้งาน
11.34 0.01 1.80 1.13 0.08 85.65
อุปกรณ์: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz wait r_await w_await svctm %util
xvda 39.75 720.61 79.81 192.29 0.99 3.57 34.30 0.02 0.09 0.19 0.04 0.09 2.53
^[[A^[[A^[[Aavg-cpu: %user %nice %system %iowait %steal %ไม่ได้ใช้งาน
84.15 0.00 6.16 0.05 0.03 9.61
อุปกรณ์: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz wait r_await w_await svctm %util
xvda 0.80 31.00 14.40 19.80 0.65 0.20 50.95 0.02 0.73 0.93 0.58 0.43 1.48
^[[A^[[Bavg-cpu: %user %nice %system %iowait %steal %ไม่ได้ใช้งาน
84.54 0.00 4.95 0.10 0.05 10.36
อุปกรณ์: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz wait r_await w_await svctm %util
xvda 0.00 2.40 22.60 1.60 1.77 0.02 151.40 0.02 1.02 1.04 0.75 0.64 1.56
ยูลิมิต -a
ขนาดไฟล์หลัก (บล็อก, -c) 0
ขนาด data seg (kbytes, -d) ไม่จำกัด
การจัดลำดับความสำคัญ (-e) 0
ขนาดไฟล์ (บล็อก, -f) ไม่จำกัด
สัญญาณที่รอดำเนินการ (-i) 128341
หน่วยความจำสูงสุดที่ล็อกไว้ (kbytes, -l) 64
ขนาดหน่วยความจำสูงสุด (kbytes, -m) ไม่จำกัด
เปิดไฟล์ (-n) 1024
ขนาดไปป์ (512 ไบต์, -p) 8
คิวข้อความ POSIX (ไบต์, -q) 819200
ลำดับความสำคัญตามเวลาจริง (-r) 0
ขนาดสแต็ก (kbytes, -s) 10240
เวลาซีพียู (วินาที, -t) ไม่จำกัด
กระบวนการของผู้ใช้สูงสุด (-u) 128341
หน่วยความจำเสมือน (kbytes, -v) ไม่จำกัด
ล็อคไฟล์ (-x) ไม่จำกัด
ฉันตรวจสอบบันทึกการค้นหาทั่วไปหลังจากตรวจสอบบันทึกการค้นหาที่ช้า และรู้สึกประหลาดใจที่ฉันได้รับข้อความค้นหามากมาย เมื่อการจราจรเป็นปกติ ฉันได้รับ: 136235 ข้อความค้นหา ซึ่งส่วนใหญ่เป็นข้อความค้นหา SELECT หลังจากผ่านไป 10 นาที และเมื่อมีการจราจรหนาแน่น ฉันได้รับ: 195650 ข้อความค้นหาใน 10 นาที ฉันสงสัยว่าเป็นผู้เข้าชม 195650 คน แต่ด้วยเหตุผลบางประการ การโทรอยู่ใน General_log slow_query_log มีเพียง 4 ข้อความค้นหา และดูเหมือนไม่ใช่ข้อความค้นหาที่ไม่ได้เพิ่มประสิทธิภาพ มีอะไรอีกบ้างที่ฉันควรดู หรือนี่เพียงพอที่จะคาดเดาว่ามันมาจากการรับส่งข้อมูลและเราควรอัปเกรดเซิร์ฟเวอร์หรือไม่
ด้านบนประมาณนี้ครับ ผมถ่ายไม่ทัน แต่พอถึง 95%+ cpu หน้าจอจะเป็นแบบนี้ครับ
บน - 13:04:51 อัพ 1140 วัน 19:59 น. ผู้ใช้ 2 คน โหลดเฉลี่ย: 26.57, 16.21, 8.92
งาน: ทั้งหมด 429, 12 วิ่ง, 421 นอน, 0 หยุด, 0 ซอมบี้
ซีพียู: 91.3%us, 1.6%sy, 0.0%ni, 65.7%id, 3.1%wa, 0.0%hi, 0.2%si, 0.1%st
Mem: รวม 32877280k, ใช้ไป 31367584k, ฟรี 1509696k, บัฟเฟอร์ 3960824k
สลับ: รวม 0k, ใช้ไป 0k, ฟรี 0k, แคช 3980580k
ผู้ใช้ PID PR NI VIRT RES SHR S %CPU %MEM TIME+ คำสั่ง
14576 mysql 20 0 12.9g 8.5g 8424 S 951.6 27.2 18841:47 mysqld
6032 มาร์ติน 20 0 510m 65m 9160 S 61.4 0.2 2:49.40 php-fpm
7329 มาร์ติน 20 0 498m 63m 5556 R 57.6 0.2 0:47.15 php-fpm
7321 มาร์ติน 20 0 487m 52m 5532 R 46.1 0.2 0:45.18 php-fpm
7160 มาร์ติน 20 0 488m 52m 5540 R 44.1 0.2 1:02.67 php-fpm
6031 มาร์ติน 20 0 511m 67m 8076 S 42.2 0.2 2:50.87 php-fpm
6696 มาร์ติน 20 0 498m 63m 5700 S 38.4 0.2 1:36.38 php-fpm
7283 มาร์ติน 20 0 494m 59m 5268 S 34.5 0.2 0:46.19 php-fpm
7314 มาร์ติน 20 0 490m 55m 5536 R 33.0 0.2 0:44.22 php-fpm
7330 มาร์ติน 20 0 496m 60m 5436 R 26.4 0.2 0:46.82 php-fpm
7305 มาร์ติน 20 0 494m 58m 5572 R 25.4 0.2 0:48.85 php-fpm
6706 มาร์ติน 20 0 507m 62m 8060 S 13.7 0.2 1:40.55 php-fpm
7276 มาร์ติน 20 0 498m 63m 5264 S 7.7 0.2 0:49.89 php-fpm
17464 redis 20 0 4328m 2.3g 888 R 7.7 7.3 7827:30 เซิร์ฟเวอร์ redis
6402 มาร์ติน 20 0 511m 67m 8056 S 5.8 0.2 2:15.21 php-fpm
6405 มาร์ติน 20 0 512m 69m 9204 S 5.8 0.2 2:14.32 php-fpm
6703 มาร์ติน 20 0 513m 67m 8056 S 5.8 0.2 1:39.40 php-fpm
6705 มาร์ติน 20 0 513m 68m 9040 S 5.8 0.2 1:36.18 php-fpm
7303 มาร์ติน 20 0 493m 57m 6556 วินาที 5.8 0.2 0:47.04 php-fpm
7304 มาร์ติน 20 0 494m 59m 5264 วินาที 5.8 0.2 0:48.70 php-fpm
7323 มาร์ติน 20 0 511m 67m 7772 S 5.8 0.2 0:45.53 php-fpm
24515 nginx 20 0 123m 66m 2452 วินาที 5.8 0.2 7231:17 nginx
6039 มาร์ติน 20 0 507m 63m 8200 S 3.8 0.2 2:48.39 php-fpm
6400 มาร์ติน 20 0 511m 68m 8204 S 3.8 0.2 2:13.54 php-fpm
6401 มาร์ติน 20 0 510m 66m 9052 S 3.8 0.2 2:13.36 php-fpm
6404 มาร์ติน 20 0 512m 68m 9048 S 3.8 0.2 2:12.75 php-fpm
เนื่องจากมีการสืบค้น SQL จำนวนมากเมื่อมีแนวโน้มที่จะช้าลงมาก ฉันคิดว่ามันเกิดจากการรับส่งข้อมูลสูง ฉันตรวจสอบ cronjobs (cronjobs ของ wordpress และ php cronjobs) และดูเหมือนว่าไม่มีอะไรทำงานเมื่อมันช้า อาจมีกระบวนการ rsync ทำงานพร้อมกัน แต่กระบวนการ rsync ทำงานตลอดเวลา ดังนั้นฉันจึงสงสัยว่าเกิดจากสิ่งนี้ มีอะไรที่ฉันสามารถตรวจสอบได้หรือไม่?
การวิเคราะห์สถานะสากลและตัวแปร:
ข้อสังเกต:
ปัญหาที่สำคัญกว่า:
เปลี่ยน long_query_time ถึง 1 เพื่อให้คุณสามารถรับคำถามเพิ่มเติมในสโลว์ล็อก (ตอนนี้คุณมีเวลา 10 วินาที นี่อาจอธิบายได้ว่าทำไมคุณถึงพบเพียง 4 ข้อความค้นหา)
มีเงื่อนงำหลายประการที่ข้อความค้นหาบางส่วนทำงานไม่มีประสิทธิภาพ วิธีค้นหาข้อความค้นหาดังกล่าวมีดังนี้ http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog
ทำไมคุณถึงใช้ MyISAM ค่าต่างๆ ทำให้เกิดความสับสน เหมือนกับว่าคุณสร้างดัชนีสำหรับตาราง MyISAM ขนาดใหญ่ แต่ไม่ได้ทำอะไรอย่างอื่นมากนัก ในกรณีส่วนใหญ่ ควรใช้ InnoDB จะดีกว่า
innodb_buffer_pool_size อาจเพิ่มขึ้นเพื่อปรับปรุงความเร็วในการสืบค้น InnoDB
ระมัดระวังเกี่ยวกับ ทั่วไป_log - มันเติมดิสก์ค่อนข้างเร็ว
"Query Cache" ทำงานไม่มีประสิทธิภาพ ฉันแนะนำให้ปิดอย่างสมบูรณ์: query_cache_type=ปิด และ query_cache_size=0.
Max_used_connections ตี 152 แสดงว่ามีผู้ใช้เชื่อมต่อพร้อมกันจำนวนมาก (ไม่ได้หมายความว่า 152 ข้อความค้นหาทำงานพร้อมกัน)
รายละเอียดและข้อสังเกตอื่นๆ:
การแปลงจาก MyISAM เป็น InnoDB
( key_blocks_used * 1024 / key_buffer_size ) = 460 * 1024 / 128M = 0.35% -- เปอร์เซ็นต์ของ key_buffer ที่ใช้ เครื่องหมายน้ำสูง
-- ลดขนาด key_buffer_size (ตอนนี้เป็น 134217728) เพื่อหลีกเลี่ยงการใช้หน่วยความจำโดยไม่จำเป็น
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) ) = ((128M / 0.20 + 8192M / 0.70)) / 32768M = 37.7% -- แรมส่วนใหญ่ที่มีอยู่ควรมีไว้สำหรับแคช
-- http://mysql.rjweb.org/doc.php/memory
( general_log ) = general_log = เปิด -- บันทึก (ไฟล์หรือตาราง) ของการเรียกใช้แบบสอบถามทั้งหมด
-- ปิด General_log (ตอนนี้เป็น ON) เมื่อไม่ได้ใช้งาน บันทึกนั้นสามารถเติมเต็มดิสก์ได้อย่างรวดเร็ว
( innodb_buffer_pool_size ) = 8,192 / 32768M = 25.0% -- % ของ RAM ที่ใช้สำหรับ InnoDB buffer_pool
-- ตั้งค่าประมาณ 70% ของ RAM ที่มีอยู่ (ไปที่ต่ำจะมีประสิทธิภาพน้อยกว่า การแลกเปลี่ยนความเสี่ยงสูงเกินไป)
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) ) = ((128M / 0.20 + 8192M / 0.70)) / 32768M = 37.7% -- (เมตริกสำหรับการตัดสินการใช้ RAM)( innodb_lru_scan_ความลึก * innodb_page_cleaners ) = 1,024 * 4 = 4,096 -- จำนวนงานสำหรับโปรแกรมทำความสะอาดหน้าทุกๆ วินาที
-- "InnoDB: page_cleaner: 1,000ms ตั้งใจวนลูปเอา ..." อาจแก้ไขได้โดยลดระดับ lru_scan_html: พิจารณา 1,000 / innodb_page_cleaners (ตอนนี้ 4) ตรวจสอบการแลกเปลี่ยนด้วย
( innodb_lru_scan_ความลึก ) = 1,024
-- "InnoDB: page_cleaner: 1000ms ตั้งใจวนลูปเอา ..." อาจแก้ไขได้โดยการลดระดับ lru_scan_html
( innodb_io_capacity ) = 200 -- เมื่อล้าง ให้ใช้ IOP จำนวนมากนี้
-- การอ่านอาจเฉื่อยชาหรือแหลมคม
( Innodb_log_writes ) = 43,856,157 / 1725103 = 25 /วินาที
( Innodb_os_log_written / (เวลาทำงาน / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 137,804,939,264 / (1725103 / 3600) / 2 / 48M = 2.86 -- อัตราส่วน
-- (ดูนาที)
( เวลาทำงาน / 60 * innodb_log_file_size / Innodb_os_log_written ) = 1,725,103 / 60 * 48M / 137804939264 = 10.5 -- นาทีระหว่างการหมุนบันทึก InnoDB ตั้งแต่ 5.6.8 เป็นต้นไป สามารถเปลี่ยนแปลงได้แบบไดนามิก อย่าลืมเปลี่ยน my.cnf ด้วย
-- (คำแนะนำ 60 นาทีระหว่างการหมุนค่อนข้างไม่มีกฎเกณฑ์) ปรับ innodb_log_file_size (ตอนนี้ 50331648) (ไม่สามารถเปลี่ยนแปลงใน AWS)
( innodb_flush_method ) = innodb_flush_method = fsync -- InnoDB ควรขอให้ OS เขียนบล็อกอย่างไร แนะนำ O_DIRECT หรือ O_ALL_DIRECT (Percona) เพื่อหลีกเลี่ยงการบัฟเฟอร์ซ้ำซ้อน (อย่างน้อยสำหรับ Unix) ดู chrischandler สำหรับคำเตือนเกี่ยวกับ O_ALL_DIRECT
( default_tmp_storage_engine ) = default_tmp_storage_engine =
( innodb_flush_neighbors ) = 1 -- การเพิ่มประสิทธิภาพเล็กน้อยเมื่อเขียนบล็อกลงดิสก์
-- ใช้ 0 สำหรับไดรฟ์ SSD; 1 สำหรับฮาร์ดดิสก์
( innodb_io_capacity ) = 200 - I/O ops ต่อวินาทีที่มีความสามารถบนดิสก์ 100 สำหรับไดรฟ์ช้า 200 สำหรับไดรฟ์แบบหมุน 1,000-2,000 สำหรับ SSD; คูณด้วยปัจจัย RAID
( innodb_adaptive_hash_index ) = innodb_adaptive_hash_index = เปิด -- โดยปกติควรจะเปิด
-- มีหลายกรณีที่ปิดดีกว่า ดูเพิ่มเติมที่ innodb_adaptive_hash_index_parts (ตอนนี้ 8) (หลัง 5.7.9) และ innodb_adaptive_hash_index_partitions (MariaDB และ Percona) ON มีส่วนเกี่ยวข้องกับข้อขัดข้องที่หายาก (ข้อผิดพลาด 73890) 10.5.0 ตัดสินใจที่จะปิดค่าเริ่มต้น
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = ปิด -- ไม่ว่าจะบันทึก Deadlocks ทั้งหมด
-- หากคุณประสบปัญหา Deadlocks ให้เปิดใช้งานข้อควรระวัง: หากคุณมีการชะงักงันจำนวนมาก สิ่งนี้อาจเขียนจำนวนมากลงในดิสก์
( character_set_server ) = character_set_server = ภาษาละติน1
-- ปัญหาชุดอักขระอาจช่วยได้โดยการตั้งค่า character_set_server (ตอนนี้เป็น latin1) เป็น utf8mb4 นั่นคือค่าเริ่มต้นในอนาคต
( local_infile ) = local_infile = เปิด
-- local_infile (เปิดแล้ว) = เปิด เป็นปัญหาด้านความปลอดภัยที่อาจเกิดขึ้น
( key_blocks_used * 1024 / key_buffer_size ) = 460 * 1024 / 128M = 0.35% -- เปอร์เซ็นต์ของ key_buffer ที่ใช้ เครื่องหมายน้ำสูง
-- ลดขนาด key_buffer_size (ตอนนี้เป็น 134217728) เพื่อหลีกเลี่ยงการใช้หน่วยความจำโดยไม่จำเป็น
( Key_writes / Key_write_requests ) = 19,978,377 / 40284646 = 49.6% -- ประสิทธิภาพ key_buffer สำหรับการเขียน
-- หากคุณมี RAM เพียงพอ คุณควรเพิ่มขนาด key_buffer_size (ตอนนี้เป็น 134217728)
(query_cache_size) = 524,288 = 0.5MB -- ขนาดของ QC
- เล็กเกินไป = ใช้ประโยชน์ไม่ได้มาก ใหญ่เกินไป = โอเวอร์เฮดมากเกินไป แนะนำทั้ง 0 หรือไม่เกิน 50M
( Qcache_lowmem_prunes ) = 125,234,412 / 1725103 = 73 /วินาที -- ห้อง QC หมด
-- เพิ่ม query_cache_size (ตอนนี้ 524288)
( Qcache_lowmem_prunes/Qcache_inserts ) = 125,234,412/146211296 = 85.7% --Removal Ratio (ความถี่ที่ต้องตัดเนื่องจากหน่วยความจำไม่เพียงพอ)
( Qcache_not_cached ) = 78,413,835 / 1725103 = 45 /วินาที -- SQL_CACHE พยายามแล้ว แต่ถูกละเว้น
- คิดใหม่เกี่ยวกับแคช ปรับแต่ง qcache
( Qcache_hits / Qcache_inserts ) = 37,201,050 / 146211296 = 0.254 -- อัตราการตีต่อเม็ด -- สูงก็ดี
-- พิจารณาปิดแคชแบบสอบถาม
( Qcache_hits / (Qcache_hits + Com_select) ) = 37,201,050 / (37201050 + 282029692) = 11.7% -- อัตราการเข้าชม -- เลือกที่ใช้ QC
-- พิจารณาปิดแคชแบบสอบถาม
( Qcache_hits / (Qcache_hits + Qcache_inserts + Qcache_not_cached) ) = 37,201,050 / (37201050 + 146211296 + 78413835) = 14.2% -- ค้นหาอัตราการเข้าชมแคช
-- อาจเป็นการดีที่สุดที่จะปิด QC
( (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache / query_alloc_block_size ) = (524288 - 78344) / 82/16384 = 0.332 --query_alloc_block_size เทียบกับสูตร
-- ปรับ query_alloc_block_size (ตอนนี้ 16384)
( Created_tmp_tables ) = 96,501,765 / 1725103 = 56 /วินาที -- ความถี่ของการสร้างตาราง "ชั่วคราว" โดยเป็นส่วนหนึ่งของ SELECT ที่ซับซ้อน
( Created_tmp_disk_tables ) = 23,539,653 / 1725103 = 14 /วินาที -- ความถี่ในการสร้าง ดิสก์ ตาราง "temp" เป็นส่วนหนึ่งของ SELECT ที่ซับซ้อน
-- เพิ่ม tmp_table_size (ตอนนี้ 16777216) และ max_heap_table_size (ตอนนี้ 16777216)
ตรวจสอบกฎสำหรับตารางชั่วคราวเมื่อใช้ MEMORY แทน MyISAM บางทีการเปลี่ยนแปลงสคีมาเล็กน้อยหรือแบบสอบถามอาจทำให้ MyISAM หลีกเลี่ยงได้
ดัชนีที่ดีขึ้นและการจัดรูปแบบข้อความค้นหามีแนวโน้มที่จะช่วยได้มากขึ้น
( Created_tmp_disk_tables / คำถาม ) = 23,539,653 / 414140316 = 5.7% -- ส่วนของข้อความค้นหาที่ต้องการตาราง tmp บนดิสก์
-- ดัชนีดีขึ้น / ไม่มี blobs / ฯลฯ
( Select_full_join / Com_select ) = 30,333,225 / 282029692 = 10.8% -- % ของการเลือกที่มีการรวมแบบไม่มีดัชนี
-- เพิ่มดัชนีที่เหมาะสมลงในตารางที่ใช้ในการเข้าร่วม
( Com_insert + Com_delete + Com_delete_multi + Com_replace + Com_update + Com_update_multi ) = (87669877 + 27242 + 0 + 0 + 1452911 + 0) / 1725103 = 52 /วินาที -- เขียน/วินาที
-- 50 การเขียน/วินาที + การล้างข้อมูลบันทึกอาจทำให้ความสามารถในการเขียน I/O สูงสุดของไดรฟ์ HDD หากคุณมี SSD แสดงว่าเมตริกนี้น่าจะใช้ได้
( binlog_format ) = binlog_format = ผสม -- ข้อความ/แถว/ผสม
-- ROW เป็นที่ต้องการโดย 5.7 (10.3)
( long_query_time ) = 10 -- Cutoff (วินาที) สำหรับกำหนดแบบสอบถาม "ช้า"
-- แนะนำ 2
( max_used_connections / max_connections ) = 152/151 = 100.7% -- % สูงสุดของการเชื่อมต่อ
-- เพิ่ม max_connections (ตอนนี้ 151) และ/หรือลด wait_timeout (ตอนนี้ 28800) หรือเร่งความเร็วการค้นหา
(การเชื่อมต่อ) = 11,987,448 / 1725103 = 6.9 /วินาที -- การเชื่อมต่อ
-- เพิ่ม wait_timeout (ตอนนี้ 28800); ใช้การรวม?
( Connection_errors_accept + Connection_errors_internal + Connection_errors_peer_address + Connection_errors_select + Connection_errors_tcpwrap ) = 0 + 26 + 0 + 0 + 0 = 26 -- ข้อผิดพลาดในการเชื่อมต่อนอกเหนือจาก max_connections
-- สำหรับข้อมูลเพิ่มเติม โปรดดูที่ แสดงสถานะส่วนกลาง เช่น 'Connection_errors%'
เล็กผิดปกติ:
Created_tmp_files = 0.094 /ชม
innodb_spin_wait_delay = 4
ใหญ่ผิดปกติ:
Aria_pagecache_writes = 34 /วินาที
Aria_transaction_log_syncs = 25,641
Com_show_warnings = 40 /ชม
Connection_errors_internal = 0.054 /ชม
Handler_read_key = 85109 /วินาที
Handler_tmp_update = 839 /วินาที
Innodb_buffer_pool_read_requests = 675158 /วินาที
Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads ) = 100.0%
Innodb_rows_updated = 356 /วินาที
performance_schema_max_cond_classes = 90
สตริงที่ผิดปกติ:
Innodb_have_punch_hole = ปิด
aria_recover_options = สำรองข้อมูลอย่างรวดเร็ว
unconnect_on_expired_password = ปิด
ft_boolean_syntax = + -><()~*:
innodb_fast_shutdown = 1
log_output = ตาราง
myisam_stats_method = NULLS_UNEQUAL
old_alter_table = ค่าเริ่มต้น
Optimizer_trace = เปิดใช้งาน = ปิด
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
