You can adjust MySQL's memory usage by modifying the my.cnf configuration file. For example, to double the memory allocated, you'll likely need to adjust key parameters in the configuration file that control memory usage. Here are the steps:


Key Parameters to Modify in my.cnf

1. Locate my.cnf: Typically found in one of these locations:
   
   • /etc/my.cnf
   • /etc/mysql/my.cnf
   • /usr/local/mysql/etc/my.cnf
   If you’re unsure, you can locate it with:
   mysql --help | grep my.cnf
2. Key Settings to Adjust: These are the most commonly modified settings that influence memory usage:
   
   • innodb_buffer_pool_size: The largest consumer of memory, used for caching data and indexes for InnoDB tables.
     • Example: To double the memory allocated:
       innodb_buffer_pool_size=1G # Adjust based on your available memory
   • key_buffer_size: Memory used for caching MyISAM table indexes. If you primarily use InnoDB, this can be kept low.
   • query_cache_size: If query caching is enabled, increasing this can also improve performance.
   • max_connections: Each connection consumes memory. If you allow too many concurrent connections, it can inflate memory usage.
   • tmp_table_size and max_heap_table_size: Memory allocated for temporary tables. If you expect many temporary tables, these values may need adjustment.
3. Example Adjustments:
   [mysqld] innodb_buffer_pool_size=2G key_buffer_size=256M query_cache_size=128M max_connections=200 tmp_table_size=64M max_heap_table_size=64M
4. Save and Exit: After editing my.cnf, save your changes.
   

Restart MySQL for Changes to Take EffectRestart MySQL to apply the changes:
sudo systemctl restart mysql
Monitor Memory UsageAfter restarting, monitor the memory usage to ensure the settings have taken effect:
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';" mysql -e "SHOW STATUS LIKE 'Innodb_buffer_pool_bytes_data';" Additionally, use top or htop to verify the overall memory usage.

Important Notes

• Ensure Available Memory: Verify that doubling MySQL’s memory won’t exhaust your system’s resources. Keep some buffer for the OS and other processes.
• Test Gradually: Start with smaller increases and monitor performance before doubling the memory outright.
• Backup Configuration: Save a backup of your my.cnf file before making changes.

Let me know if you’d like more guidance or tailored recommendations based on your server setup!

In cookieless mode, Matomo works great. Cookieless mode cannot detect the return of the visitor well in that mode but Matomo still gives you 90% of the data you need otherwise.

The main cookie: pk_id

Out of the box (the first time you use it), Matomo's default configuration (1) will set a pk_id cookie. By default the cookie expires in 13 months.

You can see the pk_id cookie right now: try the following.  Open the homepage of Matomo.org (screenshot above). In the browser devtools find pk_id. It is a stringified array. The array holds two things: visitorID of the person and the date the cookie was made.

config_id

The backup plan, if there is no pk_id cookie found in the browser, nor user_id found, will be the "not a fingerprint" number.





Link
1 Matomo Default Configuration: github.com/matomo-org/matomo/blob/5.x-dev/config/global.ini.php

I hate getting these messages when running core:archive in Matomo.

• WARNING   [2024-04-24 14:47:54] 6414  /var/www/littlefurnace.com/matomo/core/CliMulti/Process.php(314): Warning - shell_exec(): Unable to execute 'ps x 2>/dev/null | awk '! /defunct/ {print $1}' 2>/dev/null' - Matomo 5.0.3 - Please report this message in the Matomo forums: https://forum.matomo.org (please do a search first as it might have been reported already)
• ERROR     [2024-04-24 16:04:11] 9574  Error unserializing the following response from ?module=API&method=CoreAdminHome.archiveReports&idSite=5&period=week&date=2024-02-26&format=json&segment=actionType%3D%3Dpageviews%3Bactions%3E%3D3&plugin=Funnels&trigger=archivephp&pluginOnly=1&requestedReport=Funnels_exits_2: ''
• ERROR     [2024-04-24 16:04:11] 9574  Got invalid response from API request: ?module=API&method=CoreAdminHome.archiveReports&idSite=5&period=day&date=2024-02-15&format=json&segment=actionType%3D%3Dpageviews%3Bactions%3E%3D3&plugin=Funnels&trigger=archivephp&pluginOnly=1&requestedReport=Funnels_funnel_sum_entries_2. The response was empty. This usually means a server error. A solution to this error is generally to increase the value of 'memory_limit' in your php.ini file.  For more information and the error message please check in your PHP CLI error log file. As this core:archive command triggers PHP processes over the CLI, you can find where PHP CLI logs are stored by running this command: php -i | grep error_log

My Matomo server is a $5 shared space hosted on Digital Ocean, the cheapest deployment, the least memory, all minimal RAM, CPUs, everything. 

Frustrated by these errors, I learned to overcome these errors by running console core:archive manually and changing options until it runs well.   Here are the things I do.

1. Incrementally run longer time spans.  I run today and yesterday. Then this month. Then forever.

2. Run it once with no segments. Then run it with segments.

3. Run it with the PHP memory allocation declared at run time.


Case 1:
Got errors during the archiving, in the section before scheduled tasks.
Added the option --skip-all-segments. Still errors.
Deleted the segment from the UI. Success!  (Not sure why the option didn't do the trick.)

​Case 2 (September 2024 update) 
1. Tons of errors: sudo su www-data -s /bin/bash -c  "php   -d memory_limit=8G  /var/www/matomo/console core:archive" 
2. Zero errors: sudo su www-data -s /bin/bash -c  "php   -d memory_limit=8G  /var/www/littlefurnace.com/matomo/console core:archive --skip-all-segments --force-idsites=2"
Conclusion: On underpowered servers, you can eliminate errors by doing one site at a time and by skipping segments."

Then go back and do the segments, still doing only one site at a time
3.  sudo su www-data -s /bin/bash -c  "php   -d memory_limit=8G  /var/www/littlefurnace.com/matomo/console core:archive  --force-idsites=1"
​

Do you want to see cookies appearing and disappearing, and expiry times changing, in your browser?

For setting Cookie Consent (this is the yes/no after a visitor clicks your "accept all cookies" banner):

1. Open a page which has Matomo tracking (the normal JS tracker)
2. In Devtools >> Console, do the following _paq.push(['rememberCookieConsentGiven']);
3. (in devtools >> storage/cookies see the expiry date of the mtm_cookie_consent cookie is very far in the future)
4. In the console again _paq.push(['rememberCookieConsentGiven', 47]);
5. (in devtools >> storage/cookies see the expiry date of the mtm_cookie_consent cookie is now two days in the future)

There is an entire parallel process for tracking in general (not just cookies).  Repeat every line above the same but remove the word cookie from methods in push.

Links
Easy: https://matomo.org/faq/new-to-piwik/how-can-i-still-track-a-visitor-without-cookies-even-if-they-decline-the-cookie-consent/
More detail: https://developer.matomo.org/guides/tracking-consent
List of most of the cookies: https://matomo.org/faq/general/faq_146/
List of some innocent cookies: https://matomo.org/faq/general/faq_157/
ALL 200 JS METHODS FOR THE CONSOLE: 
https://developer.matomo.org/api-reference/tracking-javascript

Errors which say Something happened, Unable to create, or Unable to write are caused by lack of permission. Your server user-name is usually www-data or sometimes apache.

To fix this error do all of the steps, in order.

1. Which server do you use: Apache, Nginx, Windows? Please find the configuration file. See what "user name" it runs things as. You can discover this by searching the web server config file for "user" and "group". Confirm that it is www-data. Or go list your files to see the group name and owner name ls -l /var/www/html/matomo/tmp
2. sudo chown -R www-data:www-data /var/www/html/matomo # I am assuming www-data was found in Step 1
3. sudo find /var/www/html/matomo/tmp -type f -exec chmod 644 {} \;
4. sudo find /var/www/html/matomo/tmp -type d -exec chmod 755 {} \;
5. sudo find /var/www/html/matomo/tmp/assets -type f -exec chmod 644 {} \;
6. sudo find /var/www/html/matomo/tmp/assets -type d -exec chmod 755 {} \;
7. sudo find /var/www/html/matomo/tmp/assets -type f -exec chmod 644 {} \;
   
   

Tokens generated by users, starting in Matomo 5, should keep unchecked the box "Only allow secure requests" if the token is meant for a GET request.  However it is recommended that you check this box, and get in the habit of sending tokens in POST requests instead.

Certain operations by modules like Looker Studio Matomo Connector require a GET request from Google. So in that case, generate the token with the box NOT checked.

If your site gets more than 100,000 pageviews per month, you must, must, must enable core:archive. And you must disable browser based archiving.  This can be done in the config/config.ini.php file.

How long does core:archive take to run
A very large site with 12M hits per day (300M hits per month) can take 8 hours to finish the core:archive. This is with some CPU-intensive options enabled, like uniqueness and segments.  Here is one example of a real site which takes 8 hours:

• They have 100 defined segments
  
• They get ~12M hits a day
  
• The largest segments returns 5M visits for the iOS segment
  

Is PHP installed?
sudo apt update
sudo apt install php

There are two!
Matomo runs two PHPs. One is on the Apache server for the Matomo backend. The other is the PHP for the CLI, which executes the core:archive command

PART ONE: JUST CHECKING THE SERVER PHP WHERE REPORTS AND TRACKING HAPPEN
Check memory and the version of PHP in the web server which serves your Matomo Interface
First, make a serveable phpinfo(); page. I placed mine at https://littlefurnace.com/foobarbaz.php
Then serve that page, in the browser. Or from CURL. 
In Curl: curl https://littlefurnace.com/foobarbaz.php | grep memory

In your browser, the classic pink and blue PHP information page will appear. 

This will have important information about the memory_limit, the path to where the configuration files are, and the PHP version you are running.


PART TWO: JUST CHECKING THE CLI ENVIRONMENT PHP, WHERE CORE:ARCHIVE AND OTHER CONSOLE COMMANDS ARE EXECUTED

Check memory and the version of PHP in CLI (for Matomo core:archive) 
IMPORTANT The core:archive of Matomo uses the PHP settings of CLI, not of the web server.
php -i | grep memory_limit
To find the path to the config file where you can edit things like  memory_limit
php -i | grep -i config

Example in my Matomo CLI environment
This:
php -i | grep -i config
Returns this:
Loaded Configuration File => /etc/php/8.1/cli/php.ini
So edit that file to look like this:
memory_limit=6G

Is PHP enabled for Apache?
sudo apt install libapache2-mod-php
(restart Apache)
sudo systemctl restart apache2

Configuration
Check the PHP configuration file (php.ini) to ensure that the disable_functions directive does not include any module that you need!
Find the php.ini
php -i | grep php.ini
Then, edit the php.ini file
And restart server
sudo systemctl restart apache2

Increase PHP memory in Matomo
A typical Matomo error is
Allowed memory size of 4294967296 bytes exhausted

Typical steps to fix this error:
Find the php.ini
php -i | grep php.ini
Then, edit this line in the php.ini file
memory_limit=8G
And restart server
sudo systemctl restart apache2

(Or, if you want to experiment on-the-fly with benchmarking the performance, you can actually override the memory limit directly, including in the crontab, using an option
such as: php -d memory_limit=2G /var/www/html/console core:archive )

A less common, laborious, alternative solution to prevent the php process from using too much memory is only process a specific number of reports at a time in order. We can achieve this by using a combination of --force-periods and --force-date-range in the core:archive task to process only a few specific reports for each core:archive run: For example: php path/to/matomo/console core:archive --force-idsite=13 --force-periods=day,week,month --force-date-range=2021-01-01,2021-01-31 And then repeat this process for each month that the reports were invalidated for.

The Matomo pageview event can be manually observed in your browser devtools.

In the case above we have configured a Javascript tracker on our website (pikl.us website) to monitor pageviews. The deluxe twist is we are sending the pageview to two Matomo servers. We set this up using the instructions here: https://matomo.org/faq/how-to/how-do-i-send-tracking-requests-to-two-or-more-matomo-servers/

Since it is easy (and catastrophic to data) to miss a pageview event, we want to confirm that we set it up correctly. (It's a common mistake to set up two servers and later discover that the data is uneven because you are only sending to the most recently set server.) Let's troubleshoot this in Developer Tools in the browser.

To confirm the pageviews are actually happening, do the following:

1. Open up devtools in your browser. Go to browser >> other tools >> developer tools >> network tab
2. Enter the URL of your website you want to monitor
3. Find a pair of requests. They will likely be POST http requests and they will have no payload, hence the size will be 0 kilobytes.
4. It's easy to see the request(s) by filtering for .php extension in the filter bar.
5. Success! In the screenshot above you can see that we have a pair of POST requests going to our endpoints of littlefurnace.com/matomo/matomo.php and tatll.matomo.cloud/matomo.php.  The hypertext transfer protocol content of the request is shown in the right margin of the devtools window

In my case, the POST request contains the following:

https://tatll.matomo.cloud/matomo.php?action_name=pikL&
idsite=6&
rec=1&
r=333268&
h=9&
m=13&
s=44&
url=https://pikl.us/linksPage.php&
_id=675de8e438add64b&
_idn=0&
send_image=0&
_refts=0&
pdf=1&
qt=0&
realp=0&
wma=0&
fla=0&
java=0&
ag=0&
cookie=1&
res=2560x1080&
pv_id=U80TLm&
pf_net=292&
pf_srv=72&
pf_tfr=0&
uadata={}

If you would like to learn more about the parameters in the request, see the Matomo parameters documentation here:
https://developer.matomo.org/api-reference/tracking-api

TODO:
Specific examples of troubleshooting, Type 2 and Type 3, will be added here in the future.

Typical Error Message:
mmap() failed: [12] Cannot allocate memory
PHP Fatal error:  Out of memory (allocated 94896128) (tried to allocate 35651616 bytes) in /var/www/littlefurnace.com/matomo/vendor/pear/archive_tar/Archive/Tar.php on line 1907

Remedy:
#1
Find where the file is for your PHP settings. The location is variable. PHP language is installed in the same machine where your web server for Matomo is running.  Look up how to run phpinfo(). This pink and blue page will show the location of your PHP settings:

#2 Now look inside that file. Find the memory setting. Change it to something like memory_limit = 2G

$ head /etc/php/8.2/fpm/php.ini
$ grep memory /etc/php/8.2/fpm/php.ini
$ sudo nano /etc/php/8.2/fpm/php.ini
$ sudo systemctl restart apache2