Minnesota Web Developer | A little something about everything...

Minnesota Web Developer

A little something about everything...

TLC vs MLC vs SLC, Performance, benchmarks and reliability.

SLC, Single Level Cell (1 bit)

  • Generally 100000 write erase cycles
  • Erase time: 1-2.5ms

MLC, Multilevel Cell (2 or more bits)

  • Anywhere from 3000 to 15000 write erase cycles
  • Erase time: 2.5-3.5ms

TLC, Triple Level Cell (3 bits)

  • Anywhere from 1000 to 5000 write/erase cycles
  • Erase time: 4-5ms

 

Currently TLC offers the best performance/reliability per $ due to the fact that its the cheapest software and reliability has been improved exponentially over the past few years. MLC is also fairly close in performance/reliability per $, overall a MLC 2 bit cell has about 3x more write/erase cycles than a 3 bit cell so enterprise products tend to be MLC or SLC as SLC does have the best overall reliability with generally is well over 100,000 write/erase cycles ten times that of a MLC unit without software optimizations. Since software can be used to improve the overall reliability issues things can get quite complicated.

First thing to consider is amount of data you will be writing to the drive each day and how long you need the drive to last as SSD drives will all fail at some point based on number of write/erase cycles to the drive.

If the data is static, meaning very little writing/erasing to the drive then go with TLC,

If you plan to have moderate to heavy data writes/rewites/erasing then MLC or SLC, for example mail or database server.

With standard 3x Write Amplification* and 20GB a day in new data writes a 128GB SLC drive should last about 5-6 years and a MLC drive should last about 17-18 years assuming nothing else with the drive fails before that. In a enterprise environment you might have 40GB/day and the lifespan would drop to 2.5-3 years on SLC or 8.5-9 years on a MLC disk.

Enterprise vs Consumer grade SSD's:

The real difference between consumer grade SSD and enterprise grade is how efficiently the drive handles data read/write/erase cycles and sometimes its just marketing so check the MTBF; this should be 1,000,000 at a minimum. Next you will want to check the IOPS(input/outputs per second); in most cases you should look for something with 80,000 or more for both read and write.

Note on SLC:

Because very few people need a drive to last longer than 5-10 years SLC has not had much development keeping the price high and size very small, this is why most people choose MLC or TLC SSD drives today. 

 

Write Amplification is when SSD cells are erased before being written, this is required. when data is written to the disk the flash controller updates the LBA with the location of the data/metadata any old data still remains on the disk and must be erased. Some drives can offer solutions to this by methods like over provisioning, allowing new data to be written next to the old data without fragmentation and erasing the old data improving performance and the life of the disk but lowering the capacity. Another method it to separate static and dynamic data sets reducing the erase cycles for content that is rarely changed allowing the firmware to be more efficient and rotate usage over the life of the drive. 

This message wasn't delivered to anyone because it's too large. The limit is 10 MB. This message is / 550 5.2.3 RESOLVER.RST.SendSizeLimit.Org; message too large for this organization

Error:

This message wasn't delivered to anyone because it's too large. The limit is 10 MB. This message is

This message won't be sent because it's too large

#550 5.2.3 RESOLVER.RST.SendSizeLimit.Org; message too large for this organization ##

 

Solution:

Adjust the limits with the following powershell commands:

 Set-TransportConfig -InternalDsnMaxMessageAttachSize #MB

 Set-TransportConfig -ExternalDsnMaxMessageAttachSize #MB

then

 Set-TransportConfig -MaxReceiveSize #MB -MaxSendSize #MB

or

 Set-Mailbox "User" -MaxSendSize #MB -MaxReceiveSize #MB

Gmail rejecting exchange 2010 2013 emails with: The sender does not meet basic ipv6 sending guidelines of authentication and rdns resolution of sending ip.

Issue:

gmail.com is rejecting emails from Microsoft Exchange 2010 and Microsoft Exchange 2013 email servers for no PTR records even if you do not have any IPv6 IPs assigned to the server.

 

Error:

The sender does not meet basic ipv6 sending guidelines of authentication and rdns resolution of sending ip. Please review https://support.google.com/mail/answer/81126for more information.

Your message wasn't delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept email from certain senders, or another restriction may be preventing delivery.

Diagnostic information for administrators:

Generating server: EXCHANGE.a51.biz

{email address}
mx.google.com #550-5.7.1 [ipv6info] The sender does not meet basic 550-5.7.1 ipv6 sending guidelines of authentication and rdns resolution of 550-5.7.1 sending ip. Please review 550 5.7.1 https://support.google.com/mail/answer/81126 for more information.

 

Solution:

Disable certain IPv6 components yourself, follow these steps:

  1. Use the registry editor to edit the following path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
    • Edit or create DWORD (32-bit) value "DisabledComponents".
    • Default value is "0", you will need to change this to "0xffffffff"(Hexadecimal "ffffffff" or Decimal "4294967295") in order to disable all IPV6 other than local loopback.
  2. Verify that IPV6 is disabled with the following command: "reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents"
    • You may receive the following error message: "ERROR: The system was unable to find the specified registry key or value."
    • If you receive this error message, the DisabledComponents registry value is not set. If the DisabledComponents value is set, it overrides the settings in the connection properties.

Solution 2:

If you have IPv6 IP's enabled on the server verify that your PTR records are correctly setup.

Microsoft Exchange RPC Client Access fails due to high memory usage in Microsoft® SharePoint® Search Component (aka noderunner.exe) on Exchange 2013

After installing exchange 2013 and migrating clients over to the server you may notice Microsoft® SharePoint® Search Component or noderunner.exe running multiple instances with high memory usage. This is because Microsoft has integrated parts of sharepoint into exchange 2013. This process runs when accounts are first migrated and periodically to index email data stores for OWA in order to make search results fast, very fast.

You can disable Microsoft Exchange Search Host Controller service if it is causing an issue. In some cases it can consume an extremely high amount of memory causing the "Microsoft Exchange RPC Client Access" to fail and get stuck in a starting state. In which case the best solutions are to:

  • Increase the amount of RAM on the server.
  • Set the server to restart when "Microsoft Exchange RPC Client Access" fails. 
  • Disable the "Microsoft Exchange Search Host Controller service".

This is an obvious flaw in the design of exchange 2013 server.