New answers tagged configuration
Actually, with shared_buffers = 3000MB, Postgres does take "a lot" of RAM (relatively speaking for a system with 8 GB) - even if not all the RAM, like you may have been thinking. And the "why" is obvious: because you instructed it with your setting for shared_buffers. The setting is high (default is 128MB), for a dedicated DB server the setting seems still ...
PostgreSQL isn't using lots of RAM, the kernel is using it for disk cache. This is exactly what you want to happen. There is nothing to fix here. "Free" RAM is wasted RAM. The best thing for a database server is for as much RAM as possible to be used as disk cache.
The new MySQL Router is one possible solution. Please take a look and let us know what you think! I'd love to hear what features you most want in future versions. http://mysqlhighavailability.com/mysql-router-on-labs-the-newest-member-of-the-mysql-family/ http://mysqlhighavailability.com/easy-load-balancing-and-high-availability-using-mysql-router/
I had the same problem with my MySql 5.6.10 version, and the following helped me. Try adding the following in your my.ini (or my.cnf) file under the [mysqld] part: table_definition_cache = 400 performance_schema=0 and restart your mysql server. In my case after doing the above my mysql server's RAM usage went down from ~430MB to ~20 MB. You can read ...
Aye aye. You are confusing megabytes and gigabytes (MB is even in the configuration name!). EXEC sys.sp_configure N'max server memory (MB)', N'96' --<-- this is 96 MB GO EXEC sys.sp_configure N'max server memory (MB)', N'98304' --<-- this is ~96 GB GO
EXEC sys.sp_configure N'max server memory (MB)', N'96' GO RECONFIGURE WITH OVERRIDE GO The above will set it to 96MB which will starve SQL Server. The max memory is in MB not GB. Below will set Max memory to 96000MB (96*1024 = 98304MB to be precise) equivalent to 96GB: EXEC sys.sp_configure N'max server memory (MB)', N'98304' GO RECONFIGURE WITH ...
Keeping things cached with PostgreSQL is a balance between what you can have in shared_buffers and what you have in the filesystem cache, and avoiding both of them being pushed out by other processes. One of the first things you can do on PostgreSQL 9.4 is set huge_pages=on in your postgresql.conf. This also involves doing some OS changes to allow ...
The most likely explanation is that your queries are being executed using different execution plans on the new server, due to changes in statistics, index size and density, and configuration settings. The configuration settings that have the biggest impact on query optimizer execution plan choices are: max server memory max degree of parallelism cost ...
I ran into this problem upgrading from mongo that comes with Centos 7 Repos, to the Mongos own repos. In effect upgrading from V2 to V3. Turns out that centos 7 repo requires the user mongodb, while mongos own repo wants the user mongod In the end it was the log file that still existed from the old installation that the new installation couldn't write to, ...
This is a permission issue. when we change path of data directory or log file then we have to give permissions to the new directory. Then it runs fine. If any problem occurred like this firstly check the log file "mongod.log".
A PRIMARY KEY is a UNIQUE KEY; remove the second of these: PRIMARY KEY (`id`), UNIQUE KEY `id` (`id`), You might gets a slight performance improvement by adding this composite index to peer_engagement: INDEX(is_intensive, status_id) innodb_buffer_pool_size 134217728 change to about 70% of available RAM unless you are running in a small VM. ...
If you are using 2008 R2 and above(I can see you tagged question as SQL Server 2014) you can use DMV sys.dm_server_registry to get all information about registry values for SQL Server. Just go to SSMS and run below select * from sys.dm_server_registry If you want to filter out parameters related to SQL Server startup SELECT r.registry_key, ...
In SQL Server 2008 R2 SP1 or later, this is made considerably easier via the sys.dm_server_registry DMV: SELECT DSR.registry_key, DSR.value_name, DSR.value_data FROM sys.dm_server_registry AS DSR WHERE DSR.registry_key LIKE N'%MSSQLServer\Parameters'; From: An easier way to get SQL Server startup parameters
Top 50 recent answers are included