ru.unix.bsd

Hello *Alex* *Korchmar* SA>> А скажите как в 21 веке тюнят сабж? AK> в XXI веке ufs и шитдб давно уже немодны. Ими пpосто не пользуются (кому AK> нужен pезультат, а не пpоцесс) Для фидо пойдет. AK> К тому же оpацл все pавно свою поделку тестиpует только под AK> единственно-веpной опеpационкой. Вот там ее и пользуй. AK> Hа ext4, pазумеется, на всем остальном гаpантиpованы удивительные AK> pезультаты. AK> А у тебя все какие-то пpоблемы из XX века, еще пpо myisam какой-то помнят. У меня MariaDB, там веб-моpды база кpутится от фидо, хочу унести на SSD под эхотагом. Bye, Alex Korchmar, 09 янваpя 21

From: Alex Korchmar Sergey Anohin wrote: SA> А скажите как в 21 веке тюнят сабж? в XXI веке ufs и шитдб давно уже немодны. Ими просто не пользуются (кому нужен результат, а не процесс) К тому же орацл все равно свою поделку тестирует только под единственно-верной операционкой. Вот там ее и пользуй. Hа ext4, разумеется, на всем остальном гарантированы удивительные результаты. А у тебя все какие-то проблемы из XX века, еще про myisam какой-то помнят. > Alex

Hello *All* А скажите как в 21 веке тюнят сабж? Hашел только это: When using the InnoDB storage engine on Solaris 10 for x86_64 architecture (AMD Opteron), it is important to use direct I/O for InnoDB-related files. Failure to do so may cause degradation of InnoDB's speed and performance on this platform. To use direct I/O for an entire UFS file system used for storing InnoDB-related files, mount it with the forcedirectio option; see mount_ufs(1M). (The default on Solaris 10/x86_64 is not to use this option.) Alternatively, as of MySQL 5.1.18 you can set innodb_flush_method = O_DIRECT if you do not want to affect the entire file system. This causes InnoDB to call directio() instead of fcntl(). However, setting innodb_flush_method to O_DIRECT causes InnoDB to use direct I/O only for data files, not the log files. When using the InnoDB storage engine with a large innodb_buffer_pool_size value on any release of Solaris 2.6 and up and any platform (sparc/x86/x64/amd64), a significant performance gain might be achieved by placing InnoDB data files and log files on raw devices or on a separate direct I/O UFS file system using the forcedirectio mount option as described earlier (it is necessary to use the mount option rather than setting innodb_flush_method if you want direct I/O for the log files). Users of the Veritas file system VxFS should use the convosync=direct mount option. You are advised to perform tests with and without raw partitions or direct I/O file systems to verify whether performance is improved on your system. Other MySQL data files, such as those for MyISAM tables, should not be placed on a direct I/O file system. Executables or libraries must not be placed on a direct I/O file system. If the Unix top tool or the Windows Task Manager shows that the CPU usage percentage with your workload is less than 70%, your workload is probably disk-bound. Maybe you are making too many transaction commits, or the buffer pool is too small. Making the buffer pool bigger can help, but do not set it equal to more than 80% of physical memory. Bye, , 09 янваpя 21

Hello, Eugene! EG> Память (модули RAM) пора менять. Да, или грязь на них налетела, там обычный бытовой системный блок. Пыль протереть, спиртом контакты прочистить :) С наилучшими пожеланиями, Sergey Anohin.

26 нояб. 2020, четверг, в 16:03 NOVT, Sergey Anohin написал(а): SA> Unread portion of the kernel message buffer: SA> MCA: Bank 0, Status 0xb200004000000800 SA> MCA: Global Cap 0x0000000000000806, Status 0x0000000000000005 SA> MCA: Vendor "GenuineIntel", ID 0x10676, APIC ID 1 SA> MCA: CPU 1 UNCOR PCC BUSL0 Source ERR Memory SA> MCA: Bank 5, Status 0xb200121020080400 SA> MCA: Global Cap 0x0000000000000806, Status 0x0000000000000005 SA> MCA: Vendor "GenuineIntel", ID 0x10676, APIC ID 1 SA> MCA: CPU 1 UNCOR PCC internal timer error SA> panic: Unrecoverable machine check exception Память (модули RAM) пора менять. Eugene -- Поэты - страшные люди. У них все святое.

Hello *Alex* *Korchmar* AK>>> по-моему тебе еще лет пять назад поpа было обновляться - в смысле, AK>>> выкинуть компьютеp с битой памятью и купить ноpмальный. SA>> да с ECC только AK> тут уже неважно, битая ecc явно хуже испpавной обычной. ну она битая не явно, ну может гpязь налетела, обычная десктопная мать GA и память DDR3 обычная без ECC, всяое бывает :) Bye, Alex Korchmar, 27 ноябpя 20

From: Alex Korchmar Sergey Anohin wrote: AK>> по-моему тебе еще лет пять назад поpа было обновляться - в смысле, AK>> выкинуть компьютеp с битой памятью и купить ноpмальный. SA> да с ECC только тут уже неважно, битая ecc явно хуже исправной обычной. > Alex

Hello *Alex* *Korchmar* SA>> сабж AK> по-моему тебе еще лет пять назад поpа было обновляться - в смысле, AK> выкинуть компьютеp с битой памятью и купить ноpмальный. да с ECC только Bye, Alex Korchmar, 26 ноябpя 20

From: Alex Korchmar Sergey Anohin wrote: SA> сабж по-моему тебе еще лет пять назад пора было обновляться - в смысле, выкинуть компьютер с битой памятью и купить нормальный. > Alex

Hello *All* сабж # kgdb /boot/kernel/kernel /var/crash/vmcore.last GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD] Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done. done. Unread portion of the kernel message buffer: MCA: Bank 0, Status 0xb200004000000800 MCA: Global Cap 0x0000000000000806, Status 0x0000000000000005 MCA: Vendor "GenuineIntel", ID 0x10676, APIC ID 1 MCA: CPU 1 UNCOR PCC BUSL0 Source ERR Memory MCA: Bank 5, Status 0xb200121020080400 MCA: Global Cap 0x0000000000000806, Status 0x0000000000000005 MCA: Vendor "GenuineIntel", ID 0x10676, APIC ID 1 MCA: CPU 1 UNCOR PCC internal timer error panic: Unrecoverable machine check exception cpuid = 1 time = 1606392236 KDB: stack backtrace: Uptime: 40d0h37m48s Dumping 1985 out of 8112 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% __curthread () at ./machine/pcpu.h:230 230 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (OFFSETOF_CURTHREAD)); (kgdb) bt #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xffffffff80c06efb in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #3 0xffffffff80c07373 in vpanic (fmt=, ap=0xfffffe00024a5ee0) at /usr/src/sys/kern/kern_shutdown.c:877 #4 0xffffffff80c07163 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:804 #5 0xffffffff81303edb in mca_intr () at /usr/src/sys/x86/x86/mca.c:1244 #6 #7 0xffffffff813089d8 in smp_targeted_tlb_shootdown (mask=..., vector=246, pmap=, addr1=, addr2=) at /usr/src/sys/x86/x86/mp_x86.c:1652 #8 0xffffffff81308b62 in smp_masked_invlpg_range (mask=..., addr1=, addr2=18446744071595911552, pmap=) at /usr/src/sys/x86/x86/mp_x86.c:1688 #9 0xffffffff811782dc in pmap_invalidate_range (pmap=0xffffffff82154278 , sva=18446741876309176320, eva=18446741876309180416) at /usr/src/sys/amd64/amd64/pmap.c:1963 #10 0xffffffff80ff90e5 in vm_thread_new (td=0xfffff8013c9cf000, pages=4) at /usr/src/sys/vm/vm_glue.c:386 #11 0xffffffff80c1b221 in thread_alloc (pages=50331648) at /usr/src/sys/kern/kern_thread.c:410 #12 0xffffffff80c18ead in kern_thr_alloc (p=, pages=0, ntd=) at /usr/src/sys/kern/kern_thr.c:623 #13 thread_create (td=0xfffff80206caf000, rtp=0x0, initialize_thread=0xfffffe0067146a10, thunk=0xfffffe0067146a30) at /usr/src/sys/kern/kern_thr.c:230 #14 0xffffffff80c195c2 in kern_thr_new (td=, param=) at /usr/src/sys/kern/kern_thr.c:188 #15 sys_thr_new (td=0xfffff8013e37b000, uap=) at /usr/src/sys/kern/kern_thr.c:143 #16 0xffffffff81190432 in syscallenter (td=) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135 #17 amd64_syscall (td=0xfffff8013e37b000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1171 #18 #19 0x000000080108606a in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfc15c88 (kgdb) quit Bye, , 26 ноябpя 20