Difference file name should be set
explicitly for database on raw device

а кто-нибудь тестировал на реальной нагрузке, оно таки стоит своих свеч?

МП писал(а) Tue, 02 July 2024 17:28

а кто-нибудь тестировал на реальной нагрузке, оно таки стоит своих свеч?

Как показывает практика, на raw-диске файловое кэширование ОС не работает. А значит работает только кэширование Firebird. А оно не очень того. Например, там нет "предиктивного чтения", которое есть в файловом кэше ОС.
Так что, работать-то оно будет но мееееедленно.
Не зря все нынешние ОС оставляют 50% RAM под кэш ФС.Которых у ФБ на raw не будет в принципе. Понятно-то что ФБ файловый кэш напрямую не использует, но без него будет худо.

Как показывает практика...

С бюджетными и даже "просто серверными" SSD "под базу данных" есть фундаментальная проблема - деградация параметров под реальной нагрузкой.
СУБД (довольно быстро) записала полный объём диска, закончился SLC-кэш и всё - аллес капут.

щупал не я, но я подглядывал
естественно, на линуксе, не на винде

С бюджетными и даже "просто серверными" SSD "под базу данных" есть фундаментальная проблема - деградация параметров под реальной нагрузкой.
СУБД (довольно быстро) записала полный объём диска, закончился SLC-кэш и всё - аллес капут.

basid писал(а) Wed, 17 July 2024 12:58

С бюджетными и даже "просто серверными" SSD "под базу данных" есть фундаментальная проблема - деградация параметров под реальной нагрузкой.
СУБД (довольно быстро) записала полный объём диска, закончился SLC-кэш и всё - аллес капут.

Проблема сильно преувеличена.
Например, в нашем случае, SSD 128-256Гб, несколько баз по 20-40Гб, 20-40 пользователей к каждой базе.
На SSD только базы.
За 5 лет ресурс выюзывается на 3-7%, соответственно 93% еще остается.

kdv писал(а) Wed, 17 July 2024 00:21

щупал не я, но я подглядывал
естественно, на линуксе, не на винде

Тогда у меня есть плохая старость: блочные девайсы в /dev Линух кэширует так же как и обычные файлы.

Проблема сильно преувеличена.
Например, в нашем случае, SSD 128-256Гб, несколько баз по 20-40Гб, 20-40 пользователей к каждой базе.
На SSD только базы.
За 5 лет ресурс выюзывается на 3-7%, соответственно 93% еще остается.

Device Statistics (GP Log 0x04)
       Value Flags Description
           =  ===  == General Statistics
        1043  ---  Lifetime Power-On Resets
 52023594730  ---  Logical Sectors Written
   798321302  ---  Number of Write Commands
128708198877  ---  Logical Sectors Read
  5654194037  ---  Number of Read Commands
           =  ===  == Solid State Device Statistics
           3  N--  Percentage Used Endurance Indicator
              |||_ C monitored condition met
               ||__ D supports DSN
                |___ N normalized value

ID# ATTRIBUTE_NAME          RAW_VALUE
  5 Reallocated_Sector_Ct               0
  9 Power_On_Hours                  40351
 12 Power_Cycle_Count                1043
165 Block_Erase_Count       1542122245167
166 Minimum_PE_Cycles_TLC              13
167 Max_Bad_Blocks_per_Die             26
168 Maximum_PE_Cycles_TLC              65
169 Total_Bad_Blocks                  245
170 Grown_Bad_Blocks                    0
171 Program_Fail_Count                  0
172 Erase_Fail_Count                    0
173 Average_PE_Cycles_TLC              35
174 Unexpected_Power_Loss              63
184 End-to-End_Error                    0
187 Reported_Uncorrect                  0
188 Command_Timeout                     0
194 Temperature_Celsius     35 (Min/Max 17/49)
199 UDMA_CRC_Error_Count                0
232 Available_Reservd_Space           100
233 NAND_GB_Written_TLC             18097  # 17,7 ТБ
234 NAND_GB_Written_SLC             37806  # 36,9 ТБ
241 Host_Writes_GiB                 24806  # 24,2 ТБ
242 Host_Reads_GiB                  61372  # 59,9 ТБ

Model Family:     WD Blue / Red / Green SSDs
Device Model:     WDC WDS500G2B0A-00SM50
Firmware Version: X61190WD
User Capacity:    500 107 862 016 bytes [500 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic, zeroed
Device is:        In smartctl database 7.3/5528
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Thu Jul 18 15:06:34 2024 RTZ
Rd look-ahead is: Enabled
Write cache is:   Enabled
DSN feature is:   Unavailable
ATA Security is:  Disabled, frozen [SEC2]
Wt Cache Reorder: Unavailable

меньше 10% свободного места под NTFS на любом диске фундаментальная проблема

           3  N--  Percentage Used Endurance Indicator
              |||_ C monitored condition met
               ||__ D supports DSN
                |___ N normalized value

           3  N--  Percentage Used Endurance Indicator
              |||_ C monitored condition met
              ||__ D supports DSN
              |___ N normalized value

pastor писал(а) Wed, 17 July 2024 14:51

меньше 10% свободного места под NTFS на любом диске фундаментальная проблема

Да-да-да. А ещё своп-файл должен быть вдвое больше объёма ОЗУ. Не надо вот этих древних историй про "убить NTFS созданием-удалением миллионов мелких файлов".
NTFS-диск, на котором осталось 4 килобайта (один кластер) свободного места я лично наблюдал в начале десятых на Windows Server 2003. И, что характерно, ничего не сломалось и продолжило штатно работать после того, как я "раскидал" файлы по более-менее свободным дискам. Даже не потребовался "root-овый резерв".
Если вы когда-то работали с NT4 или даже с NT3.5, то не надо думать, что с тех пор вообще ничего не поменялось.

блочные девайсы в /dev Линух кэширует так же как и обычные файлы.

echo 3 > /proc/sys/vm/drop_caches; dd if=/dev/sda of=/dev/null bs=16M status=progress

echo 3 > /proc/sys/vm/drop_caches; dd iflag=direct if=/dev/sda of=/dev/null bs=16M status=progress