I've read and re-read DO's description of threads created and can't for the life of me figure out what's going on. Is this really implying that 650000 threads are being created every second? That can't be right.
Someone help me decipher what this graph implies please.
I'm using EFF certbot ACME client to generate a single TLS certificates on my webserver that is hosting multiple domains using Subject Alternative Names (SAN). Up until now all of the domains where hosted in a specific Digital Ocean team, and I have certbot configured with the Digital Ocean DNS plugin and a personal access token created for that team to generate a certificate with multiple domains (including wildcard domains).
Now a client wants me to also serve a domain that they want to retain full control of, so we created a new Digital Ocean team and my account where the DO personal access token was created has been given access to. Unfortunately, I also found out that personal access token are created for a team and cannot be used with another team.
I looked through the certbot docs but could not find how to configure different DO credentials for different domains for the same SAN certificate - is this even possible?
If not - what other alternatives would you suggest to implement this use case?
I have a laravel application which I've installed on a 1GB standard droplet running ubuntu 20.4, nginx, MySQL 8 and php 7.4
The application isn't even live yet and I notice it's already using over 60% memory - 68%
Below is a snap shot of the current high memory running processes. Is this level of memory usage normal for a laravel application which is not even live i.e. limited load?
top - 15:47:51 up 1 day, 23:53, 1 user, load average: 0.00, 0.01, 0.00
Tasks: 100 total, 3 running, 97 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.3 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 981.3 total, 89.5 free, 612.3 used, 279.5 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 200.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
815 mysql 20 0 1306168 408208 2892 S 0.3 40.6 18:20.97 mysqld
2259 www-data 20 0 244024 38424 25504 S 0.0 3.8 0:05.27 php-fpm7.4
388 root 19 -1 106512 38196 37008 S 0.0 3.8 0:06.24 systemd-journal
2265 www-data 20 0 244032 37988 25108 S 0.0 3.8 0:05.14 php-fpm7.4
2257 www-data 20 0 244004 37780 24856 S 0.0 3.8 0:05.22 php-fpm7.4
988 root 20 0 125160 30236 4640 S 0.3 3.0 2:03.41 php
741 root 20 0 649232 22700 6672 S 0.0 2.3 0:17.61 snapd
544 root rt 0 280180 17976 8184 S 0.0 1.8 0:11.26 multipathd
743 root 20 0 31348 16972 2468 S 0.0 1.7 0:31.63 supervisord
738 root 20 0 238392 13208 7244 S 0.0 1.3 0:09.45 php-fpm7.4
726 do-agent 20 0 559692 11852 5560 S 0.0 1.2 0:20.79 do-agent
825 root 20 0 108036 11804 4160 S 0.0 1.2 0:00.10 unattended-upgr
736 root 20 0 29220 11364 3708 S 0.0 1.1 0:00.11 networkd-dispat
1 root 20 0 168752 10208 5772 S 0.0 1.0 0:12.03 systemd
15532 sammy 20 0 18556 8488 6948 S 0.0 0.8 0:00.08 systemd
778 www-data 20 0 71004 8276 3552 S 0.0 0.8 0:02.71 nginx
15522 root 20 0 13760 8256 6816 S 0.0 0.8 0:00.01 sshd
623 systemd+ 20 0 23912 6756 2752 S 0.0 0.7 0:00.60 systemd-resolve
15634 osama 20 0 13892 5912 4452 S 0.0 0.6 0:00.06 sshd
747 root 20 0 16860 5564 4552 S 0.0 0.6 0:02.54 systemd-logind
15635 sammy 20 0 10032 5104 3412 S 0.0 0.5 0:00.04 bash
15537 sammy 20 0 169820 4572 0 S 0.0 0.5 0:00.00 (sd-pam)
763 root 20 0 12160 4504 3572 S 0.0 0.4 0:01.33 sshd
621 systemd+ 20 0 18544 4292 3276 S 0.0 0.4 0:01.11 systemd-network
659 root 20 0 18880 3808 2528 S 0.0 0.4 0:01.92 systemd-udevd
My concern is once the application goes live and the load increases, more database connection it going to run out of memory. I know I can resize the droplet and increase the memory or set up some swap space but is this amount of memory usage normal for an unused laravel application?
How can I optimize the high memory usage processes such as mysql, niginx, php. Looks like mysql8 is the main culprit hogging all the memory. Below are the mysql8 settings:
#
# The MySQL database server configuration file.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
# Here is entries for some specific programs
# The following values assume you have at least 32M ram
[mysqld]
#
# * Basic Settings
#
user = mysql
# pid-file = /var/run/mysqld/mysqld.pid
# socket = /var/run/mysqld/mysqld.sock
# port = 3306
# datadir = /var/lib/mysql
# If MySQL is running as a replication slave, this should be
# changed. Ref https://dev.mysql.com/doc/refman/8.0/en/server-system- variables.html#sysvar_tmpdir
# tmpdir = /tmp
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
#
# * Fine Tuning
#
key_buffer_size = 16M
# max_allowed_packet = 64M
# thread_stack = 256K
# thread_cache_size = -1
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover-options = BACKUP
# max_connections = 151
# table_open_cache = 4000
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
#
# Log all queries
# Be aware that this log type is a performance killer.
# general_log_file = /var/log/mysql/query.log
# general_log = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
# slow_query_log = 1
# slow_query_log_file = /var/log/mysql/mysql-slow.log
# long_query_time = 2
# log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
# server-id = 1
# log_bin = /var/log/mysql/mysql-bin.log
# binlog_expire_logs_seconds = 2592000
max_binlog_size = 100M
# binlog_do_db = include_database_name
# binlog_ignore_db = include_database_name
Any tips and advice much appreciate as this is the first time I'm using a vps.
*** UPDATE ***
Further to advice from tim, switching off mysql performance schema has made a huge difference I now get the following:
top - 10:33:26 up 5 days, 18:39, 1 user, load average: 0.01, 0.03, 0.00
Tasks: 114 total, 1 running, 107 sleeping, 6 stopped, 0 zombie
%Cpu(s): 0.7 us, 0.3 sy, 0.0 ni, 98.7 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 981.3 total, 253.8 free, 360.9 used, 366.7 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 449.2 avail Mem
I have a django app hosted on digitalocean with gunicorn and nginx.
I have just changed something in settings.py.
I have taken my SECRET_KEY and now I stored it in etc/secret_key.txt
with open('/etc/secret_key.txt') as f:
SECRET_KEY = f.read().strip()
Do I have to restart anything in order to make the changes active?
How can I check if everything is working fine and settings.py can actually import from the txt-file?
Thx for help and stay healthy!
We switched from a custom block storage solution to DigitalOcean's object storage and I'm kind of disappointed in the speed.
Is there anyway we could retrieve objects asynchronously? Also some objects that are around 50 KB can take from 57 ms to 3 seconds... Is this normal for object storage solutions or is this just an issue with DigitalOcean?
After battling with support for the past week, I finally got an acceptable response:
"Our Spaces team are aware of some possible performance bottlenecks and are working on addressing those." - Mike G., Platform Support Advocate
I did notice, a day after I submitted a support request (2017-12-18 ), the average speed was 0.74 seconds (with an avg. file size of 78.6 KB) before the NYC3 storage went down. Now it's at 0.42 seconds with an avg. file size of 88.48 KB, tested on 2017-12-20.