Month: July 2024

Mysql/Mariadb 优化

Mysql/MariadbLeave a comment

我不擅长数据库优化，但是今天在stackoverflow上看到有perl脚本来提供优化的suggestion，真心不错

这个脚本的名字叫MySqlTuber

The MySQLTuner script assesses your MySQL installation, and then outputs suggestions for increasing your server’s performance and stability.

Download the MySQLTuner script:

wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl

Change the scripts permissions to be executable:

chmod +x mysqltuner.pl

Run the mysqltuner.pl script. You will be prompted to enter in your MySQL administrative login and password:

./mysqltuner.pl

The script will return results similar to the output below:

>> MySQLTuner 1.4.0 - Major Hayden <[email protected]>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password:
[OK] Currently running supported MySQL version 5.5.41-0+wheezy1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in InnoDB tables: 1M (Tables: 11)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 11

-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 47s (113 q [2.404 qps], 42 conn, TX: 19K, RX: 7K)
[--] Reads / Writes: 100% / 0%
[--] Total buffers: 192.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 597.8M (60% of installed RAM)
[OK] Slow queries: 0% (0/113)
[OK] Highest usage of available connections: 0% (1/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/99.0K
[!!] Query cache efficiency: 0.0% (0 cached / 71 selects)
[OK] Query cache prunes per day: 0
[OK] Temporary tables created on disk: 25% (54 on disk / 213 total)
[OK] Thread cache hit rate: 97% (1 created / 42 connections)
[OK] Table cache hit rate: 24% (52 open / 215 opened)
[OK] Open file limit used: 4% (48/1K)
[OK] Table locks acquired immediately: 100% (62 immediate / 62 locks)
[OK] InnoDB buffer pool / data size: 128.0M/1.2M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
Variables to adjust:
query_cache_limit (> 1M, or use smaller result sets)

MySQLTuner offers suggestions regarding how to better the database’s performance. If you are wary about updating your database on your own, following MySQLTuner’s suggestions is one of the safer ways to improve your database performance.

Mariadb 无故宕机

Debian, Mysql/MariadbLeave a comment

最近有一台VM上的mariadb总是无故crash，在stackoverflow上搜了一下，发现了一些简单的debug方法。

其实对于大部分的mariadb无故crash来说，基本都是内存满了.

1 先检查mariadb状态, 这个不用说大家都会

systemctl status mariadb

2 如果出现了SIGKILL，那基本上都是OOM Killer干掉了, 那你就可以通过如下命令来查看是哪个process被干掉了

dmesg -T | egrep -i 'killed process'

也可以通过下面的命令来查看全部log

dmesg -T | less

 

Stackoverflow上的其他辅助回答:

The first is to look at your configuration for your webserver and the database (and presumably there some application tier in here as well) to ensure that they don’t try to use up more RAM than you have available. Since you didn’t tell us about the application server nor the webserver I can’t really advise (but here’s a hint for pre-fork Apache, optionally with PHP). As for Mariadb – go get a copy of mysqltuner.pl and run it against your installation.

That should prevent you running out of memory most of the time, but you should also reduce the amount of non-existent memory the kernel will hand out:

sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=20

and try lower values for the ratio if you are still seeing OOM killer.

 

BTC各种地址

CryptoLeave a comment

BTC常用的address有legacy, Segregated Witness( SegWit in short), Native SegWit, Taproot

Legacy address 以1开头

SegWit address 以3开头

Native SergWit address 以bc1开头

Segregated Witness – or SegWit in short – reduced the transaction data’s size to allow for faster transactions, better scalability and decreased fees.

Native SegWit (bech32) enhanced this even further and includes even lower fees.

Taproot is brand new and is not widely accepted.

Not all exchanges and wallet providers support sending Bitcoin to a Native SegWit address yet

Transactions between all 3 address types are possible.

Can I Send BTC to a SegWit Address?
You can send BTC to a SegWit address from both legacy and SegWit addresses. The Bitcoin network supports transactions between different types of addresses to maintain compatibility and ensure users can send and receive Bitcoin regardless of the address format they use.

If you prioritize maximum compatibility, SegWit (P2SH) might be the better choice. For the lowest fees and if you mostly interact with platforms that support it, native SegWit (Bech32) is preferable.