Some notes about MySQL and PostgreSQL. Ceph's Storage clustering and KVM virtualization. Programming with NodeJS and PHP. Hacking with RaspberryPI and Arduino.
Linux offers three timestamps for files: time of last access of contents (atime), time of last modification of contents (mtime), and time of last modification of the inode (metadata, ctime).
… Ext4 provides timestamps measured in nanoseconds. In addition, ext4 also adds support for date-created timestamps.
But there no consensus in the community on that so
… as Theodore Ts’o points out, while it is easy to add an extra creation-date field in the inode (thus technically enabling support for date-created timestamps in ext4), it is more difficult to modify or add the necessary system calls, like stat() (which would probably require a new version) and the various libraries that depend on them (like glibc). These changes would require coordination of many projects. So even if ext4 developers implement initial support for creation-date timestamps, this feature will not be available to user programs for now.
Let’s wait five years and see if there is actually any consensus on it being needed and used at all, rather than rush into something just because “we can”.
So what to do? Let’s chill out
Now let’s question yourself how would you extract this information? We end up with the STAT utility
NAME
stat - display file or file system status
SYNOPSIS
stat[OPTION]... FILE...
DESCRIPTION
Display file or file system status.
and DEBUGFS utilities
NAME
debugfs - ext2/ext3/ext4 file system debugger
SYNOPSIS
debugfs [-Vwci][-b blocksize ][-s superblock ][-f cmd_file ][-R request ][-d data_source_device ][ device ]
DESCRIPTION
The debugfs program is an interactive file system debugger. It can be used to examine and change the state of an ext2, ext3, or ext4 file system.
device is the special file corresponding to the device containing the file system (e.g /dev/hdXX).
If you had no success with previous one find out with the query
mysql> SHOW GLOBAL VARIABLES LIKE 'tmpdir';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| tmpdir | /tmp |
+---------------+-------+
1 row in set(0.00 sec)
Let’s make sure that MySQL intensively writing in this folder using great iwatch command
Now check how faster is scrolling the listing in iwatch /tmp.
This optimization will be useful also for many other services such as anti-viruses, PHP and web servers, Java and so on.
Actually your server is working hard managing multiple attempts to login, especially in such frameworks like
Wordpress and Joomla. The saturation of database connections results in Denial-of-Service and the website downtimes!
To block the unsolicited requests and avoid website downtimes we just need to follow some steps
Nowadays we inherit a lot of old databases.
The typical problem is to extract data from badly encoded fields.
This happens when the browser encoding is forced to let say UTF8
and MySQL is accepting the the default LATIN1 encoding. In this case
the problem does not manifests immediately since the byte sequence corresponding to
the single character remains immute during the saving and retrieval, but become a problem
when dumped and migrated.
Lets get workaround this problem. At first find non ASCII characters in the dump file
If you ever woundered why your 10Gbit link on Proxmox node is used only by a few percent during the migration, so you came to the right place.
The main reason is the security measures taken to protect virtual machine memory during the migration. All volume of memory will be transmitted via secure tunnel and that penalizes the speed:
Nov 24 12:26:41 starting migration of VM 123 to node 'proxmox1'(10.0.1.1)
Nov 24 12:26:41 copying disk images
Nov 24 12:26:41 starting VM 123 on remote node 'proxmox1'
Nov 24 12:26:43 starting ssh migration tunnel
Nov 24 12:26:43 starting online/live migration on localhost:60000
Nov 24 12:26:43 migrate_set_speed: 8589934592
Nov 24 12:26:43 migrate_set_downtime: 0.1
Nov 24 12:26:45 migration status: active (transferred 133567908, remaining 930062336), total 1082789888)
Nov 24 12:26:47 migration status: active (transferred 273781779, remaining 788221952), total 1082789888)
...
Nov 24 12:26:58 migration status: active (transferred 1036346176, remaining 20889600), total 1082789888)
Nov 24 12:26:58 migration status: active (transferred 1059940218, remaining 11558912), total 1082789888)
Nov 24 12:26:59 migration speed: 64.00 MB/s - downtime 54 ms
Nov 24 12:26:59 migration status: completed
Nov 24 12:27:02 migration finished successfuly (duration 00:00:21)
TASK OK
If your configured your Proxmox cluster to use the dedicated network isolated from the public one so you may low down the security level
Nov 24 12:42:19 starting migration of VM 100 to node 'proxmox2'(10.0.1.2)
Nov 24 12:42:19 copying disk images
Nov 24 12:42:19 starting VM 100 on remote node 'proxmox2'
Nov 24 12:42:35 starting ssh migration tunnel
Nov 24 12:42:36 starting online/live migration on 10.0.1.2:60000
Nov 24 12:42:36 migrate_set_speed: 8589934592
Nov 24 12:42:36 migrate_set_downtime: 0.1
Nov 24 12:42:38 migration status: active (transferred 728684636, remaining 5655494656), total 6451433472)
Nov 24 12:42:40 migration status: active (transferred 1465523175, remaining 4865253376), total 6451433472)
....
Nov 24 12:42:55 migration status: active (transferred 7115710846, remaining 69742592), total 6451433472)
Nov 24 12:42:55 migration speed: 323.37 MB/s - downtime 262 ms
Nov 24 12:42:55 migration status: completed
Nov 24 12:42:58 migration finished successfuly (duration 00:00:39)
TASK OK
now you’re using all available bandwidth for migration, that also is very useful during migration heavy loaded instances.
