Shogun

You cannot unpack them because they are compiled into binary. That's why it's called cython.

You don't see it because it's from the devil library. Maybe you have the wrong version installed, or none at all. Try installing devil from ports or something, though it looks like you are using FreeBSD 7 and it's not going to work.

Yeah, it's called cython.

So yesterday I got a PM asking for help optimizing a MySQL server and I though Icould just as well share what would be my answer with everyone. First of all make sure you are using a recent version of MySQL (5.6 at least) or MariaDB (10.3 or newer) as they generally should perform better than older versions. Upgrading your MySQL is easy - just uninstall the current version (ie: pkg delete mysql55-server) and install the new one (pkg install mysql57-server). You can find what is the currently installed version with pkg info. You may need to also uninstall and install the client separately. Note that when you uninstall MySQL it doesn't delete you data so you should be able to start your upgraded server straight away, unless you're moving to a very different version - in that case you may need to run mysql_upgrade, through newer versions of MySQL and MariaDB will do this themselves. Regardless, it's a good idea to make a backup first: either a physical copy (meaning, just copy the files in /var/db/mysql elsewhere, but stop the mysql service first to avoid table corruption!) - if we are using a still supported version we can install again in case of a problem - or backing up with mysqldump if we aren't. If you have been using your own my.cnf file for a long time, installing a new version will not replace it with fresh defaults, which means you may be using obsolete settings here that will prevent mysql from starting - just check your MySQL log at /var/db/mysql/<yourhostname>.err after starting the service to make sure everything is fine. So now that we are running a recent version, let's get to optimization proper. I am not going to explain how to find yourself what to optimize - that's what Database Administration degrees are for. I will just point you to some useful tools. It is recommended, in the first place, that you migrate as many tables as you can to InnoDB. If you use Navicat, and even if you don't, this is a very trivial task. ZFS tuning for MySQL If you have a good amount of InnoDB tables and you are using the ZFS filesystem (OVH installs ZFS by default for example) you may want to set up specific filesystems for them to match the block size of the InnoDB tables. Caution, this procedure is not advised for begginers: First thing, add these settings to my.cnf under the [mysqld] part (if these settings already exist, change them accordingly) innodb_data_home_dir = /var/db/mysql-innodb innodb_log_group_home_dir = /var/db/mysql-innodb-logs Stop the mysql-server service if it's running and then move your mysql directory: mv /var/db/mysql /var/db/mysql-bak Then in the shell execute these commands to create our custom filesystems for InnoDB: zfs create -o recordsize=16k -o primarycache=metadata zroot/var/db/mysql-innodb zfs create -o recordsize=128k -o primarycache=metadata zroot/var/db/mysql-innodb-logs zfs create -o recordsize=8k zroot/var/db/mysql Now let's copy the following files to their appropiate locations (you may not have all of these - it's ok, just skip it then) cp /var/db/mysql-bak/ib_logfile* /var/db/mysql-innodb-logs/ cp /var/db/mysql-bak/ib_buffer_pool /var/db/mysql-innodb/ cp /var/db/mysql-bak/ibdata* /var/db/mysql-innodb/ cp /var/db/mysql-bak/ibtmp* /var/db/mysql-innodb/ cp -r /var/db/mysql-bak/* /var/db/mysql/ Now start the mysql server and check the logs to make sure there's no errors; then once you're sure you can delete the /var/db/mysql-bak folder. Tuning tools First things first. The easiest way to set the host, user and password for all the MySQL related tools is to create a file named /root/.my.cnf and grant chmod 600 to it so other users can't read our password. [client] user=root password=whatever port=3306 socket=/tmp/mysql.sock This way we will log in automatically without the need to specify the same options over and over. MySQLTuner MySQLTuner is a popular perl script that will give you actionable suggestions to improve performance of your mysql server. Personally I prefer Percona Toolkit but this is a good starting point for beginners nevertheless as it's very easy to read the output. cd /root fetch [Hidden Content] perl mysqltuner.pl After entering user and password of our MySQL server, it will spit a number of statistics and recommendations. For more information and command line options: [Hidden Content] Percona Toolkit Percona Server is, in fact, a drop in replacement for MySQL, just like MariaDB. Personally, I haven't tested it because their FreeBSD support seems sketchy. Nevertheless, we can find a port of their auxiliary tool package "percona-toolkit", which provides more insightful recommendations that MySQLTuner. Not all the tools in the kit do work, as some rely in linux commands and nobody cared to adapt them to FreeBSD (I said that the support was sketchy!), but some of the most useful ones do: pt-duplicate-key-checker Find duplicate indexes and foreign keys on MySQL tables. pt-index-usage Read queries from a log and analyze how they use indexes pt-query-digest Analyze MySQL queries from logs, processlist or tcpdump pt-table-usage Analyze how queries use tables. pt-variable-advisor Analyze MySQL variables and advise on possible problems (Similar to MySQLTuner suggestions) Usage examples of Percona Toolkit, with the two tools I found the most useful for beginners. Index usage reads a slow query log and suggests indexes to remove, while variable advisor shows suggestions similar to MySQLTuner: pt-index-usage -F /root/.my.cnf /var/db/mysql/slow.log pt-variable-advisor "S=/tmp/mysql.sock" That's all for now. Don't expect miracles for running automated tools - those tools don't know your hardware specs, your goals and needs, or whether you are running other software in the machine. These are all important considerations - giving MySQL all the memory for itself is not a good idea if your Metin server is in the same machine for example. Use them to help you understanding what can be changed and the effect it has, and don't just implement suggestions blindly. And remember some of the settings in MySQL If you have performance problems and can't sort them out, try using a default my.cnf or deleting all the optimizations you made - sometimes reverting to defaults is the best option.

A small update - I decided to revert to using MariaDB 10.4 instead because our Log DB is running on MariaDB and the upgrade to MySQL 8 would involve a full dump and restore which would take hours with the server offline (50 GB of data there) Another reason is neither percona toolkit or xtrabackup, two tools I wanted to try out recently (more on this in a new post) do not have a FreeBSD port that is compatible with MySQL 8.

FreeBSD is the best decission YMIR made. I don't get the obsession with porting it to a system just because it's more popular. There's a reason Netflix, Apple and Sony use it.

Wow where did you find this? That's really early stuff. Too bad the ninja didn't look like that

I had those crashes with skills or mobs which had 0 as damage if I recall correctly, in any case if your syslog has 18k lines and your syserr 2 somethin is seriously wrong. Dump your skill_proto table and paste the SQL here.

You should start by posting syserr, and maybe syslog if it's not too big

what

check skill_proto, there's some affect flag regarding this iirc

This is one of those things that sound cool on paper yet no player would want to use this.

All I see there is you need to run mysql_upgrade, and if your server is in the same machine as this MySQL server, then you should restrict connections to localhost and use the SSH tunnel option in Navicat to connect yourself. Other than that, I don't see anything relevant. In my.cnf: bind-address = 127.0.0.1 socket = /tmp/mysql.sock Then edit the CONFIG files in your cores and make sure they are using either SOCKET or 127.0.0.1 as connection IP. And then show the syserr in your db and game core.

Hi there, I'm sure you've found yourself into the situation where logs grow out of proportion and maybe fill your disk, especially if your metin2 server binary went into a loop of some kind. Or maybe your nginx or mysql logs grow so big that it takes 10 seconds just to open them. Of course you could just delete them and let them recreated, but a much cleaner solution is to let the syslog daemon keep your logs neatly ordered for you. For example, we can rotate the current log to a backup file (such as myserver.log.1) once it reaches a certain size, or we can do it every day, or every week; we can even use both criteria at the same time. Once the criteria is met for a second time, myserver.log will become myserver.log.1 and myserver.log.1 will become myserver.log.2, and so on. We can keep as many backups as we want too, and the oldest file will get deleted once rotation time comes. This ensures that the logs will never take more space on disk than the size limit we set, multiplied by the number of log files to keep. So let's say we want to rotate our metin2 server logs. First take a look at /etc/newsyslog.conf to see how it looks like. You can write directly to this file, but it would get overwritten when upgrading FreeBSD, so let's do this the proper way and create a new file called /etc/newsyslog.d/<application>.conf Each line corresponds to a log and each value is separated by a TAB: <location of the log file> <user:group> <mode> <logs to keep> <size limit> <time> <flags> <pid> Where user:group is the user owning the log file; mode the permissions set (such as 644); size limit is the size in kilobytes at which the log will be automatically rotated; time is a specially formatted string defining a time of the day, month or week for the logs to be rotated; flags define whether we want to compress the old logs and other options; and pid the path to the process id we have to signal. If this means nothing to you don't worry, I will give you a couple of ready made examples right now. Example A > Rotate game logs every time they grow to 4MB in size, keep 6 old logs, and compress them with gzip: ee /etc/newsyslog.d/metin2.conf /home/metin2/channel1/game1/syslog metin2:metin2 644 6 4096 * CZ /home/metin2/channel1/game1/pid.game /home/metin2/db/syslog metin2:metin2 644 6 4096 * CZ /home/metin2/db/pid.db (you can repeat this for each core) Example B > Rotate MySQL logs every monday at 4am, keep 3 old logs, and compress them with gzip: ee /etc/newsyslog.d/mysql.conf /var/db/mysql/myhostname.err mysql:mysql 644 3 @W1D4 * CZ /var/db/mysql/myhostname.pid Example C > Rotate NGINX logs every day at midnight, do not keep any old log: ee /etc/newsyslog.d/nginx.conf /var/log/nginx-access.log www:www 644 0 @T00 * C /var/run/nginx.pid /var/log/nginx-error.log www:www 644 0 @T00 * C /var/run/nginx.pid How do we know if we did it properly? Well, the system will send us a message if something is wrong, but only if we set a mail address for root mail to be forwarded to. By default FreeBSD sends error messages to the root account which we can read in the console using the "mail" command but since this is quite primitive let's have all mail sent to our e-mail: ee /etc/aliases Below this text: # Pretty much everything else in this file points to "root", so # you would do well in either reading root's mailbox or forwarding # root's email from here. Add this line, replacing the bracketed text with your email address: root:<your email here> Save and exit and then enter this command in the shell: newaliases Ready! Now you should receive system email in your own mailbox.

That's basically the same thing I told you to do - reinstall pkg from scratch. Why do you ask for help and then ignore the answer?

It was one of those genius ideas from the owner of TEC Interactive. He bought a license for some third rate chinese MMO and tried to pass it as something related to Metin.

I believe this forum allows send private messages

Well I don't think YMIR put that there just to be annoying. The data needs to be saved on the db.

What do you mean "without wait time"? The cache is saved every hour by default, you should not change it if you don't know what you are doing. Your MySQL tables could also be corrupted, check /var/db/mysql/hostname.err

I dont't think those files are supposed to be there? They should be in a subfolder. Also this may be related to your problem:

There should be a file called list in the root of the property folder. It's a simple text file with paths on it. Also if you are using a debug client and a file is missing the client may try to find it in a real Windows path.

About the first question, you may have overwritten property/list which is a list of all the property files. You may wonder why the game needs such a list, well, once the files are packed with EterPack the game has no notion of folders or its content - it can only load files whose path is known. About the second; it may be applying a msenv file (which handles lighting, fog, etc) which you have not loaded in World Editor. Check the map folder Settings file for the msenv path.

try portsnap fetch extract cd /usr/ports/ports-mgmt/pkg/ make reinstall clean pkg update pkg upgrade then try to install mysql again

Do you want to be my kid?