BMS-HOSxP Community
HOSxP => Linux => ข้อความที่เริ่มโดย: Onsuratoom ที่ กุมภาพันธ์ 27, 2009, 13:44:33 PM
-
เรียน อ. ชัยพร เนื่องด้วยระบบการใช้งานของ HosXp มีปัญหาการใช้งานมา 1 เดือนแล้วครับ ปัญหาไม่ทราบว่าอยู่ที่ไหน คือตอนแรกมีการ Update InoDB แต่ปรากฎว่าฐานข้อมูลพังไม่สามารถเข้าโปรแกรมได้เลย จากนั้นก็ทำการย้ายเครื่อง server ใหม่ โดย Server เป็น OS ของ Linux พอย้ายมาเป็น ระบบ os windows 2003 server ก็เลยนำสำรองข้อมูลมาใช้ไปพลาง ๆ ก่อน เป็นเวลาประมาณ 1 สัปดาห์ จากนั้นทำการลง OS ใหม่ เป็น freedora แล้วทำการ config ใหม่ทั้งหมด ลง MySQL V.5 ก็ลงปกติ พอนำข้อมูลมาลงกลับใช้งานได้แค่ 20 เครื่องมากสุด ถ้ามากกว่านี้ จะขึ้น Error คือ ติดต่อกัยฐานข้อมูลไม่ได้ เนื่องจากติดต่อกับ MySQL ไม่ได้ ผมจึงขอคำแนะนำจาก อ.ด้วยครับ ตั้งแต่มีปัญหา MySQL Workload ขึ้นสูงมาก ผมได้นำ log file ส่งมาให้ตามที่ อ. ได้ขอไว้ เพราะว่าพรุ่งนี้จะทำการแก้ไขครับ
thd: 0xa0d6eb0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7fdca3b8 thread_stack 0x30000
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0xa0e0fb0 = select hn as code,concat(pname,' ',fname,' ',lname) as ptname,fathername,mathername,admit from patient where (fname_soundex like 'บ4%') or (fname like 'บุญ%') order by fname,lname limit 100
thd->thread_id=4
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
090226 08:58:09 mysqld_safe Number of processes running now: 0
090226 08:58:09 mysqld_safe mysqld restarted
InnoDB: Log scan progressed past the checkpoint lsn 1 3310940881
090226 8:58:10 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1 3311493048
090226 8:58:10 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
090226 8:58:12 InnoDB: Started; log sequence number 1 3311493048
090226 8:58:12 [Warning] 'user' entry 'root@hosxpsawang' ignored in --skip-name-resolve mode.
090226 8:58:12 [Warning] 'user' entry '@hosxpsawang' ignored in --skip-name-resolve mode.
090226 8:58:12 [Note] Event Scheduler: Loaded 0 events
090226 8:58:12 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.31' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Under GPL license as shown in the Description field.)
-
ข้อมูลเพิ่มเติม รพร.สว่างแดนดินครับ อ.MN
Server Dell 64 bit RAID 5
OS Redhat Enterprise 5.1
Mysql 5.1.31
Ram 2 GB
client > 50
คนไข้ > 700 รายต่อวัน
-
ใน /etc/my.cnf
ได้กำหนด ค่า max_connection=เท่าไรครับ
ถ้ายัง ก็กำหนด ให้เท่ากับ 200 ก็ได้
-
ต้องกำหนดด้วยหรือ เอา my.cnf ของ อ.บอยมาไม่เห็นมีกำหนด
อยู่ในส่วนไหน
จะได้ไปแก้บ้าง นะ
-
ลองส่ง my.cnf ขึ้นมาดูสิครับ :D
-
เรียน อ. ชัยพร เนื่องด้วยระบบการใช้งานของ HosXp มีปัญหาการใช้งานมา 1 เดือนแล้วครับ ปัญหาไม่ทราบว่าอยู่ที่ไหน คือตอนแรกมีการ Update InoDB แต่ปรากฎว่าฐานข้อมูลพังไม่สามารถเข้าโปรแกรมได้เลย จากนั้นก็ทำการย้ายเครื่อง server ใหม่ โดย Server เป็น OS ของ Linux พอย้ายมาเป็น ระบบ os windows 2003 server ก็เลยนำสำรองข้อมูลมาใช้ไปพลาง ๆ ก่อน เป็นเวลาประมาณ 1 สัปดาห์ จากนั้นทำการลง OS ใหม่ เป็น freedora แล้วทำการ config ใหม่ทั้งหมด ลง MySQL V.5 ก็ลงปกติ พอนำข้อมูลมาลงกลับใช้งานได้แค่ 20 เครื่องมากสุด ถ้ามากกว่านี้ จะขึ้น Error คือ ติดต่อกัยฐานข้อมูลไม่ได้ เนื่องจากติดต่อกับ MySQL ไม่ได้ ผมจึงขอคำแนะนำจาก อ.ด้วยครับ ตั้งแต่มีปัญหา MySQL Workload ขึ้นสูงมาก ผมได้นำ log file ส่งมาให้ตามที่ อ. ได้ขอไว้ เพราะว่าพรุ่งนี้จะทำการแก้ไขครับ
thd: 0xa0d6eb0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7fdca3b8 thread_stack 0x30000
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0xa0e0fb0 = select hn as code,concat(pname,' ',fname,' ',lname) as ptname,fathername,mathername,admit from patient where (fname_soundex like 'บ4%') or (fname like 'บุญ%') order by fname,lname limit 100
thd->thread_id=4
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
090226 08:58:09 mysqld_safe Number of processes running now: 0
090226 08:58:09 mysqld_safe mysqld restarted
InnoDB: Log scan progressed past the checkpoint lsn 1 3310940881
090226 8:58:10 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1 3311493048
090226 8:58:10 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
090226 8:58:12 InnoDB: Started; log sequence number 1 3311493048
090226 8:58:12 [Warning] 'user' entry 'root@hosxpsawang' ignored in --skip-name-resolve mode.
090226 8:58:12 [Warning] 'user' entry '@hosxpsawang' ignored in --skip-name-resolve mode.
090226 8:58:12 [Note] Event Scheduler: Loaded 0 events
090226 8:58:12 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.31' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Under GPL license as shown in the Description field.)
innodb ใช้ ram เกิด กว่าที่มีครับ
บอก spec เครื่องมาด้วยครับ
-
ข้อมูลเพิ่มเติม รพร.สว่างแดนดินครับ อ.MN
Server Dell 64 bit RAID 5
OS Redhat Enterprise 5.1
Mysql 5.1.31
Ram 2 GB
client > 50
คนไข้ > 700 รายต่อวัน
ตรงนี้นี่น่าจะเป็น spec ครับ อ.ood
-
เรียน อ. ชัยพร เนื่องด้วยระบบการใช้งานของ HosXp มีปัญหาการใช้งานมา 1 เดือนแล้วครับ ปัญหาไม่ทราบว่าอยู่ที่ไหน คือตอนแรกมีการ Update InoDB แต่ปรากฎว่าฐานข้อมูลพังไม่สามารถเข้าโปรแกรมได้เลย จากนั้นก็ทำการย้ายเครื่อง server ใหม่ โดย Server เป็น OS ของ Linux พอย้ายมาเป็น ระบบ os windows 2003 server ก็เลยนำสำรองข้อมูลมาใช้ไปพลาง ๆ ก่อน เป็นเวลาประมาณ 1 สัปดาห์ จากนั้นทำการลง OS ใหม่ เป็น freedora แล้วทำการ config ใหม่ทั้งหมด ลง MySQL V.5 ก็ลงปกติ พอนำข้อมูลมาลงกลับใช้งานได้แค่ 20 เครื่องมากสุด ถ้ามากกว่านี้ จะขึ้น Error คือ ติดต่อกัยฐานข้อมูลไม่ได้ เนื่องจากติดต่อกับ MySQL ไม่ได้ ผมจึงขอคำแนะนำจาก อ.ด้วยครับ ตั้งแต่มีปัญหา MySQL Workload ขึ้นสูงมาก ผมได้นำ log file ส่งมาให้ตามที่ อ. ได้ขอไว้ เพราะว่าพรุ่งนี้จะทำการแก้ไขครับ
thd: 0xa0d6eb0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7fdca3b8 thread_stack 0x30000
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0xa0e0fb0 = select hn as code,concat(pname,' ',fname,' ',lname) as ptname,fathername,mathername,admit from patient where (fname_soundex like 'บ4%') or (fname like 'บุญ%') order by fname,lname limit 100
thd->thread_id=4
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
090226 08:58:09 mysqld_safe Number of processes running now: 0
090226 08:58:09 mysqld_safe mysqld restarted
InnoDB: Log scan progressed past the checkpoint lsn 1 3310940881
090226 8:58:10 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1 3311493048
090226 8:58:10 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
090226 8:58:12 InnoDB: Started; log sequence number 1 3311493048
090226 8:58:12 [Warning] 'user' entry 'root@hosxpsawang' ignored in --skip-name-resolve mode.
090226 8:58:12 [Warning] 'user' entry '@hosxpsawang' ignored in --skip-name-resolve mode.
090226 8:58:12 [Note] Event Scheduler: Loaded 0 events
090226 8:58:12 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.31' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Under GPL license as shown in the Description field.)
ข้อมูลเพิ่มเติม รพร.สว่างแดนดินครับ อ.MN
Server Dell 64 bit RAID 5
OS Redhat Enterprise 5.1
Mysql 5.1.31
Ram 2 GB
client > 50
คนไข้ > 700 รายต่อวัน
ส่ง my.cnf มาสิครับ
ใน /etc/my.cnf
ได้กำหนด ค่า max_connection=เท่าไรครับ
ถ้ายัง ก็กำหนด ให้เท่ากับ 200 ก็ได้
ไม่ต้องกำหนดก็ใช้ได้
น่าจะติดที่ my.ini ของ mysql บน windows 2003
ตั้งค่าน้อยไปหรือเปล่า
mysql ไม่แนะนำให้ทำบน windows
-
-hardware
-software
-network
-hosxp
-mysql
-my.cnf
-table innodb
-
ส่งทั้งแฟ้มเข้ามาได้หรือเปล่าครับ (hostname.err)
-
รพร.สว่างแดนดิน ส่ง log file ให้อาจารย์
-
ดูจาก hostname.err แล้ว
ช่วงแรกของไฟล์ เหมือน innodb มันเสียครับ เหมือนมีการลบไฟล์ ib* ออกไปเลย
ทำให้ขนาดไฟล์ innodb มันไม่เท่ากับที่ hosxp มันใช้งานอยู่
ส่วนช่วงท้ายของไฟล์ มีการใช้ RAM เกินกว่าที่มีอยู่ 2 GB
อาการเดียวกับ รพร.กุฉินารายณ์ เลยครับ อ.
สามารถรัน mysql ได้ใช่ไหมครับ .... ผมเดาเอา...
ถ้าให้ clients ใช้งานจะมี error เมื่อใช้งานไปสักพักหนึ่ง เช่น การติ๊กใช้งาน soundex search แล้วพิมพ์ค้นหาชื่อคนไข้ ...ใช่หรือไม่ครับ
ถ้ารันได้ แนะนำไม่ให้ clients ใช้งานเลย แล้ว ลง Server อีกเครื่องหนึ่ง แล้วอย่าลืมปรับ my.cnf ให้เหมาะกับ RAM นะครับ
ใช้ OS อะไรก็ได้ และขอให้ใช้ mysql ที่ไม่ใช่ 5.1.31 อาจใช้ 5.1.29rc ลงไป
แล้ว ค่อย initial ให้ connect กันแค่ สอง เครื่อง พอครับ
-
ดูจาก hostname.err แล้ว
ช่วงแรกของไฟล์ เหมือน innodb มันเสียครับ เหมือนมีการลบไฟล์ ib* ออกไปเลย
ทำให้ขนาดไฟล์ innodb มันไม่เท่ากับที่ hosxp มันใช้งานอยู่
ส่วนช่วงท้ายของไฟล์ มีการใช้ RAM เกินกว่าที่มีอยู่ 2 GB
อาการเดียวกับ รพร.กุฉินารายณ์ เลยครับ อ.
สามารถรัน mysql ได้ใช่ไหมครับ .... ผมเดาเอา...
ถ้าให้ clients ใช้งานจะมี error เมื่อใช้งานไปสักพักหนึ่ง เช่น การติ๊กใช้งาน soundex search แล้วพิมพ์ค้นหาชื่อคนไข้ ...ใช่หรือไม่ครับ
ถ้ารันได้ แนะนำไม่ให้ clients ใช้งานเลย แล้ว ลง Server อีกเครื่องหนึ่ง แล้วอย่าลืมปรับ my.cnf ให้เหมาะกับ RAM นะครับ
ใช้ OS อะไรก็ได้ และขอให้ใช้ mysql ที่ไม่ใช่ 5.1.31 อาจใช้ 5.1.29rc ลงไป
แล้ว ค่อย initial ให้ connect กันแค่ สอง เครื่อง พอครับ
สวัสดีครับพี่เข้ม ตกลง รพร.กุฉิฯ ตั้งค่าการใช้ Ram ไม่เกิน 8 G. แล้วใช่เปล่าครับ
-
สวัสดีครับพี่เข้ม ตกลง รพร.กุฉิฯ ตั้งค่าการใช้ Ram ไม่เกิน 8 G. แล้วใช่เปล่าครับ
ใช่ครับ
-
ลอง Backup / Restore ข้อมูลกลับเข้าไปใหม่ครับ ถ้ายังไม่หาย อาจจะต้อง Downgrade MySQL เป็น 5.1.30 ครับ
-
ผมว่าไม่น่าจะใช่ mysql 5.1.31 อาจจะมีปัญหาจากอย่างอื่นมากกว่า
เช่น ระบบ,my.cnf ที่ทำไว้ตั้งค่ามากเกินไปหรือเปล่า อาจจะมีการปรับผิดก็ได้
-
ผมว่าไม่น่าจะใช่ mysql 5.1.31 อาจจะมีปัญหาจากอย่างอื่นมากกว่า
เช่น ระบบ,my.cnf ที่ทำไว้ตั้งค่ามากเกินไปหรือเปล่า อาจจะมีการปรับผิดก็ได้
ตามนั้นครับ
- น่าจะปรับ my.cnf
- ทำ high performance ตารางหลักๆ ดังนี้
Table : vn_stat is innodb !
Table : rcpt_print_detail is innodb !
Table : rcpt_print is innodb !
Table : patient is innodb !
Table : ovstdiag is innodb !
Table : ovst is innodb !
Table : opitemrece is innodb !
Table : opdscreen is innodb !
Table : onlineuser is innodb !
Table : lab_order is innodb !
Table : lab_head is innodb !
Table : iptdiag is innodb !
Table : ipt is innodb !
Table : incoth is innodb !
Table : incith is innodb !
Table : doctor_order_print is innodb !
Table : an_stat is innodb !
-
ยินดีต้อนรับ รพร.สว่างแดนดิน กับการกลับมาอีกครั้ง
ทราบว่า 3 วัน 3 คืน ภายใต้การดูแลของคุณ อาร์ม
พี่ลาวัลย์ คุณโจ น้องตัม คงนอนหลับสบายนะครับ
ยินดีด้วยครับ
-
ยินดีต้อนรับ รพร.สว่างแดนดิน กับการกลับมาอีกครั้ง
ทราบว่า 3 วัน 3 คืน ภายใต้การดูแลของคุณ อาร์ม
พี่ลาวัลย์ คุณโจ น้องตัม คงนอนหลับสบายนะครับ
ยินดีด้วยครับ
อยากขอให้ เล่า สู่กันฟังบ้างน่ะครับ
ใช้วิธีแก้ปัญหา กันอย่างไรบ้าง
เพื่อเป็นความรู้ครับ :)
-
ยินดีต้อนรับ รพร.สว่างแดนดิน กับการกลับมาอีกครั้ง
ทราบว่า 3 วัน 3 คืน ภายใต้การดูแลของคุณ อาร์ม
พี่ลาวัลย์ คุณโจ น้องตัม คงนอนหลับสบายนะครับ
ยินดีด้วยครับ
-ทำงานกันขนาดนั้นหรือครับ ..........ยินดีด้วยครับ....ที่ผ่านไปด้วยดี
-
จากการเข้าไป Upgrade ระบบ รพ. จังหวัดร้อยเอ็ด จาก MySQL 5.0.67 เป็น 5.1.31 พบปัญหา Lost connection โดยไม่ทราบสาเหตุ ครับ แนะนำให้ ใช้ MySQL 5.1.30 ครับ จากเดิมที่กราฟ พุ่งเกิน 50% ตลอด ตอนนี้เหลือเท่านี้แล้วครับ
กำหนดค่า MySQL ตามกระทู้นี้ครับ http://hosxp.net/index.php?option=com_smf&Itemid=28&topic=6648.0
-
จากการเข้าไป Upgrade ระบบ รพ. จังหวัดร้อยเอ็ด จาก MySQL 5.0.67 เป็น 5.1.31 พบปัญหา Lost connection โดยไม่ทราบสาเหตุ ครับ แนะนำให้ ใช้ MySQL 5.1.30 ครับ จากเดิมที่กราฟ พุ่งเกิน 50% ตลอด ตอนนี้เหลือเท่านี้แล้วครับ
กำหนดค่า MySQL ตามกระทู้นี้ครับ http://hosxp.net/index.php?option=com_smf&Itemid=28&topic=6648.0
ครับ คิดว่ามีส่วนครับ ขอบคุณครับ อ.mn
ยินดีต้อนรับ รพร.สว่างแดนดิน กับการกลับมาอีกครั้ง
ทราบว่า 3 วัน 3 คืน ภายใต้การดูแลของคุณ อาร์ม
พี่ลาวัลย์ คุณโจ น้องตัม คงนอนหลับสบายนะครับ
ยินดีด้วยครับ
ขอบคุณครับ
ไม่ถึงกับ 3 วัน 3 คืนหรอกครับ ทำเสร็จแต่วันเสาร์แล้ว แต่รอดูสถานะการก่อนครับ
ตรวจสอบแล้วมีปัญหาที่ server และ client ด้วย และยังมี virus svchost.exe โทรจัน ที่ทำให้กวนระบบ อยู่ด้วยครับ และมีการใช้ hosxp ต่างเวอชันกันด้วย
ตอนนี้ก็เลยได้เปลี่ยน linux ใหม่ และอัพเกรด MySQL เป็น 5.1.29.rc (จากเดิมใช้ 5.1.31)
ตอนนี้ก็ใช้งานปกติีดีครับ
ต้องขอบคุณ พี่ลาวัลย์ คุณโจ คุณตั้ม ที่ช่วยกันตรวจสอบหลาย ๆ อย่าง ครับ :) :)