How to use MySQLTuner on Amazon RDS

I've installed MySQLTuner locally and it works on my local database.

When I try to run it on my Amazon RDS db it does not, it says my login credentials are invalid.

$ perl mysqltuner.pl --host testing-db.??????????.us-east-1.rds.amazonaws.com --port 3306 --user admin_un --password admin_pw --forcemem 7500
[--] Performing tests on testing-db.??????????.us-east-1.rds.amazonaws.com:3306
[!!] Attempted to use login credentials, but they were invalid

I'm able to myssql normally into the RDS db locally with.

mysql -h testing-db.??????????.us-east-1.rds.amazonaws.com -P 3306 -u admin_un -p

What could I be missing here?

UPDATE

The DB is on an AWS RDS db.m3.large instance which has 2 vCPUs and 7.5GiB of RAM. I've configured the MySQL configuration settings as suggested here in an RDS Parameter Group from the AWS console.

```
SHOW VARIABLES;
auto_increment_increment 1
auto_increment_offset 1
autocommit ON
automatic_sp_privileges ON
back_log 170
basedir /rdsdbbin/mysql/
big_tables OFF
bind_address *
binlog_cache_size 32768
binlog_checksum CRC32
binlog_direct_non_transactional_updates OFF
binlog_error_action IGNORE_ERROR
binlog_format MIXED
binlog_gtid_simple_recovery OFF
binlog_max_flush_queue_time 0
binlog_order_commits ON
binlog_row_image FULL
binlog_rows_query_log_events OFF
binlog_stmt_cache_size 32768
binlogging_impossible_mode IGNORE_ERROR
block_encryption_mode aes-128-ecb
bulk_insert_buffer_size 67108864
character_set_client utf8
character_set_connection utf8
character_set_database latin1
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8
character_sets_dir /rdsdbbin/mysql-5.6.23.R1/share/charsets/
collation_connection utf8_general_ci
collation_database latin1_swedish_ci
collation_server latin1_swedish_ci
completion_type NO_CHAIN
concurrent_insert AUTO
connect_timeout 10
core_file OFF
datadir /rdsdbdata/db/
date_format %

Observations

Version: 5.6.23-log

7.5 GB of RAM

Uptime = 02:09:14; Please rerun SHOW GLOBAL STATUS after several hours.

You are not running on Windows.

Running 64-bit version

You appear to be running entirely (or mostly) InnoDB.

Important items

-
tmp_table_size = 64M

-
Review indexes and query formulation -- many are looking inefficient (by using tmp tables, etc)

-
To help in identifying the naughty queries, recommend setting long_query_time=2 and turning on the slowlog.

-
Replication is turned on, but the binlogs are being kept forever? Or does RDS purge them in some way I don't know about.

Details

( Innodb_buffer_pool_pages_free 16384 / innodb_buffer_pool_size ) = 346,833 16384 / 5705302016 = 99.6% -- % of buffer pool free
-- buffer_pool_size is bigger than working set; could decrease it (not critical)

( Uptime / 60 innodb_log_file_size / Innodb_os_log_written ) = 7,754 / 60 128M / 7059968 = 2,456 -- Minutes between InnoDB log rotations Beginning with 5.6.8, this can be changed dynamically; be sure to also change my.cnf.
-- (The recommendation of 60 minutes between rotations is somewhat arbitrary.) Adjust innodb_log_file_size.
-- Very low activity on your server

( tmp_table_size ) = 265M -- Limit on size of MEMORY temp tables used to support a SELECT
( max_heap_table_size / _ram ) = 256M / 7680M = 3.3% -- Percent of RAM to allocate when needing MEMORY table for a temp table inside a SELECT (per temp table per some SELECTs). Too high may lead to swapping. (max_heap_table_size also user limits MEMORY tables.)
-- Decrease both to, say, 1% of ram.

( local_infile ) = ON
-- local_infile = ON is a potential security issue

( Created_tmp_disk_tables ) = 45,149 / 7754 = 5.8 /sec -- Frequency of creating disk "temp" tables as part of complex SELECTs
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 45,149 / (45149 + 113444) = 28.5% -- Percent of temp tables that spilled to disk
-- Check the rules for temp tables being able to use MEMORY instead of MyISAM. It may be possible to make a minor schema or query change to avoid MyISAM.
Better indexes and reformulation of queries can also help.

-- Decrease tmp_table_size to avoid running out of RAM. Perhaps no more than 64M.

( Select_scan ) = 50,953 / 7754 = 6.6 /sec -- full table scans
( Select_scan / Com_select ) = 50,953 / 700098 = 7.3% -- % of selects doing full table scan. (May be fooled by Stored Routines.)
-- Add indexes / optimize queries (unless they are tiny tables)

( binlog_format ) = MIXED -- STATEMENT/ROW/MIXED. ROW is preferred; it may become the default.

( expire_logs_days ) = 0 -- How soon to automatically purge binlog (after this many days)
-- Too large (or zero) = consumes disk space; too small = need to respond quickly to network/machine crash.

( slow_query_log ) = OFF -- Whether to log slow queries. (5.1.12)
( long_query_time ) = 10.000000 = 10 -- Cutoff (Seconds) for defining a "slow" query.
-- Suggest ON and 2

( Com_flush ) = 12/HR
( Com_purge ) = 12/HR
-- What is doing so many FLUSHes and PURGEs? These are both rarely-used commands.

You have the Query Cache half-off. You should set both query_cache_type = OFF and query_cache_size = 0 . There is (according to a rumor) a 'bug' in the QC code that leaves some code on unless you turn off both of those settings.

StackExchange Database Administrators Q#112937, answer score: 3