Get best of the week

Memori tidak bisa dihancurkan, proses tidak bisa dihancurkan


Setelah membaca baru-baru ini ( 1 , 2 , 3 ) dengan kesulitan "ruang" prosesor apa yang diberikan, saya tanpa sadar bertanya-tanya apakah "harga" untuk besi stabil sangat tinggi, mungkin ada baiknya mengambil langkah dan, di sisi lain, membuat "perangkat lunak" tahan terhadap faktor-faktor khusus? Tetapi bukan perangkat lunak aplikasi, melainkan lingkungan pelaksanaannya: kompiler, OS. Apakah mungkin untuk melakukan eksekusi program kapan saja memungkinkan untuk menyela, me-reboot sistem dan melanjutkan dari tempat yang sama (atau hampir sama). Pada akhirnya, ada hibernasi .

Efek radiasi


Hampir semua yang terbang dari luar angkasa dapat mengganggu operasi sirkuit mikro, itu hanya masalah jumlah energi yang dibawa oleh “itu”. Bahkan foton, jika memiliki panjang gelombang sinar gamma, mampu mengatasi beberapa sentimeter aluminium dan mengionisasi atom atau bahkan menyebabkan efek fotolistrik nuklir . Sebuah elektron tidak dapat menembus rintangan padat apa pun, tetapi jika dipercepat lebih kuat, ia akan memancarkan gamma quantum saat direm dengan semua konsekuensi yang terjadi. Mengingat bahwa paruh neutron bebas adalah sekitar 10 menit, neutron langka (dan sangat cepat) mencapai kita dari Matahari. Tetapi inti dari segala sesuatu terbang dan juga mampu melakukan sesuatu. Neutrino mungkin tidak terlihat dalam hal seperti itu.

Bagaimana seseorang tidak dapat mengingat Piglet bersamanya: "sulit untuk berani ketika Anda hanya Makhluk yang Sangat Kecil."

Konsekuensi dari radiasi kosmik memasuki semikonduktor dapat berbeda. Ini adalah ionisasi atom dan pelanggaran kisi kristal dan reaksi nuklir. Di sini , doping silikon dengan neutron termal dalam reaktor atom dijelaskan , ketika Si (30) berubah menjadi P (31), dan sifat semikonduktor yang diinginkan tercapai. Tidak ada gunanya menceritakan kembali artikel indah yang disebutkan, kami hanya akan mencatat yang berikut -

  1. Beberapa efek memiliki efek jangka pendek dan tidak memiliki efek jangka panjang. Mereka dapat menyebabkan kesalahan yang dapat diperbaiki baik perangkat keras maupun perangkat lunak. Dalam kasus terburuk, reboot bisa membantu.
  2. , . - .
  3. .

Perhatikan bahwa efek tipe 2 dan 3, jika mereka dapat dihentikan, menyebabkan degradasi bertahap dari rangkaian mikro. Misalnya, jika salah satu dari (bahkan 4) penambah "hangus" dalam prosesor superscalar , Anda dapat (setidaknya secara spekulatif tidak sulit) menonaktifkan daya secara fisik kepada korban dan menggunakan tiga sisanya, di luar hanya penurunan kinerja yang akan terlihat. Demikian pula, jika salah satu register kumpulan internal rusak, itu mungkin ditandai sebagai "selalu sibuk" dan tidak akan dapat berpartisipasi dalam perencanaan operasi. Unit memori mungkin tidak tersedia. ... Tetapi jika sesuatu yang tidak dapat diperbaiki telah memburuk, Anda harus meningkatkan cadangan dingin. Jika dia.

“Ngomong-ngomong di cadangan dingin, omong-omong, tidak melindungi sirkuit mikro dari akumulasi dosis, dan bahkan dari akumulasi muatan di isolator gerbang. Selain itu, sirkuit mikro dikenal di mana degradasi dosis tanpa catu daya bahkan lebih buruk daripada dengan itu. Tetapi semua efek tunggal yang menyebabkan kegagalan keras memerlukan dimasukkannya chip. Dengan matikan, mungkin ada efek bias, tetapi mereka tidak penting untuk logika digital. " (amartologi)

Jadi, ada dua faktor

  • kapan saja, kegagalan dapat terjadi, yang diperlakukan dengan reboot
  • sistem akan secara bertahap menurun (urutan kegagalan), sebagian besar pekerjaan akan terjadi dalam kondisi degradasi parsial

Bagaimana Anda hidup dengan semua ini? Karena reservasi / tiga kali lipat dengan pemungutan suara di seluruh hierarki blok fungsional. Dengan sendirinya, tripling bukan obat mujarab, perlu untuk memahami mana dari hasil yang benar ketika salah satu komponen gagal. Kemudian komponen yang gagal dapat dimulai kembali dan diselaraskan dengan dua pekerja. Tetapi jika terjadi kegagalan, ketika komponen tidak dapat dibawa ke dalam kondisi kerja, hanya cadangan dingin, jika ada, yang akan membantu.

Bahkan jika kegagalan tidak terlihat kritis, itu dapat menyebabkan masalah serius. Misalkan kita memiliki tiga komputer yang bekerja secara serempak, di salah satu dari mereka (hipotetis, yang disebutkan di atas) salah satu dari adders gagal. Ini bukan masalah dari sudut pandang komputer yang tetap beroperasi, tetapi itu adalah masalah untuk seluruh sistem sejak saat itu komputer yang terpengaruh akan mulai terlambat secara sistematis dan upaya serius akan diperlukan untuk sinkronisasi secara keseluruhan.

Contoh lain, kegagalan memori, yang mengakibatkan beberapa rentangnya (bahkan satu halaman) menjadi tidak dapat digunakan, tidak kritis dari sudut pandang satu komputer. Setelah diagnosis, sistem operasi dapat mengatasi masalah ini tanpa menggunakan kisaran ini. Tapi dari sudut pandang sistem trojan, ini adalah bencana. Sekarang, jika ada kegagalan (yang diperlakukan dengan reboot), kita perlu membawa komputer yang gagal ke kondisi yang identik dengan yang tersisa, tetapi ini tidak mungkin karena pada komputer lain, kisaran ini berfungsi dan mungkin digunakan. Pada prinsipnya, adalah mungkin untuk melarang kisaran ini pada ketiga komputer, namun, tidak jelas bahwa hal itu akan mungkin dilakukan tanpa memulai ulang semua komputer secara bergantian.

Ini adalah situasi paradoks ketika sistem yang trojaned di tingkat atas kurang dapat diandalkan dibandingkan dengan satu komputer yang dapat beradaptasi dengan degradasi bertahap.

Perlu disebutkan pendekatan yang disebut Kunci-langkah , ketika dua core melakukan tugas yang sama dengan satu atau dua siklus clock, dan setelah itu hasilnya dibandingkan. Jika tidak sama, beberapa kode dieksekusi ulang. Ini tidak berfungsi jika ada kesalahan dalam memori atau cache umum, bagaimanapun, ia memiliki perlindungan sendiri.

Ada juga pendekatan di mana kompiler mengulangi pelaksanaan bagian dari perintah dan membandingkan hasilnya. Versi lunak Lock-step yang lembut.

Kedua pendekatan ini (terima kasihamartologiper tip) - upaya untuk mendeteksi kegagalan dan mencoba memperbaikinya dengan "sedikit darah", tanpa me-reboot. Kami akan lebih mempertimbangkan situasi ketika kegagalan serius atau kegagalan non-kritis terjadi dan reboot tidak bisa dihindari. Bagaimana memastikan bahwa program tanpa upaya khusus dari pihaknya dapat terganggu setiap saat, dan kemudian melanjutkan tanpa kerugian serius.

Bagaimana mengajar perangkat keras dan OS untuk beradaptasi dengan degradasi bertahap adalah topik untuk diskusi lain.

Bagaimana jika


Gagasan tentang memori yang stabil / persisten bukanlah hal baru dalam dirinya sendiri, jadi Dmitry Zavalishin yang terhormat (dzavalishin) mengajukan konsep ingatan persistennya . Di tangannya, ini memunculkan Phantom OS persisten , sebenarnya mesin virtual dengan overhead yang sesuai.

Mungkin, seiring waktu, teknologi MRAM atau FRAM akan matang ... saat masih mentah.

Ada juga legenda tentang komputer di atas roket R-36M (15L579?), Yang mampu diluncurkan melalui awan radioaktif segera setelah ledakan nuklir yang dekat. Memori yang diterapkan pada inti ferit kebal terhadap radiasi. Siklus perekaman memori semacam itu adalah urutan satuan mikrodetik, sehingga selama roket terbang beberapa desimeter, ada peluang fisik untuk mempertahankan konteks prosesor - isi register dan bendera. Bangun di lingkungan yang aman, prosesor terus bekerja.
Kedengarannya bisa dipercaya.

Ada beberapa tapi:

  1. Hibernasi dalam bentuk saat ini tidak cocok. Butuh usaha dan waktu. Kami berusaha melindungi diri dari kegagalan mendadak. Tidak jelas bahwa setelah kegagalan ini prosesor secara fisik mampu melakukan setidaknya sesuatu. Demikian pula, di 15L579, sistem menerima peringatan sebelum masalah dimulai dan memiliki waktu untuk melindunginya.
  2. “” — , , — . , () , .
  3. , , . — -.

Secara umum, pemulihan kerusakan pada dasarnya merupakan lawan penanganan pengecualian. Sebenarnya, kegagalan itu sendiri dalam kebanyakan kasus dimulai sebagai gangguan hardware. Perbedaannya adalah bahwa setelah pengecualian, kita hanya dapat terus bekerja, dan dalam hal ini pertama-tama kita perlu mengembalikan konteks kerja - memori dan keadaan kernel dari sistem operasi. Tetapi bagian terakhir terlihat sama.

Pertama, bagaimana seharusnya terlihat dari sisi pemrogram aplikasi.

Tampak dari luar kernel OS


Karena memulihkan dari kegagalan mirip dengan memulihkan dari melempar pengecualian, maka bekerja dengannya mungkin terlihat serupa. Misalnya, dalam C ++ kami mewarisi kelas std :: incredibleous_error dari std :: exception, tangkap di blok try / catch reguler dan atur pemrosesan.

Namun, penulis lebih menyukai semantik setjmp / longjmp (SJLJ) lebih karena:

  • ini singkat, panggil setjmp analog (& buf) dan lanjutkan pekerjaan dari tempat yang sama
  • bahkan tidak ada "& buf" yang diperlukan, hanya memanggil fungsi sistem yang menyimpan keadaan saat ini
  • selain C ++, ada bahasa besar lainnya, tidak di mana-mana ada penanganan pengecualian, tetapi di mana-mana ada panggilan ke fungsi sistem
  • dan tidak perlu memodifikasi bahasa, karena pada awalnya kami akan bertindak seminimal mungkin

Pada suatu waktu, SJLJ kalah dari teknik DWARF (secara tegas, katai hanyalah format untuk mencatat informasi) dalam penanganan pengecualian karena kinerja yang lebih buruk, kinerja tidak begitu penting di sini. Bagaimanapun, mempertahankan negara tidak akan murah, kita harus mendekatinya secara bertanggung jawab.

Tampak dari dalam kernel OS


Apa yang perlu diselamatkan, terdiri dari apa konteks proses eksekusi?

  1. Untuk setiap utas dalam mode pengguna - “jmp_buf” saat ini dengan register yang diperlukan, ini berarti bahwa OS harus menghentikan semua utas proses panggilan sebelum menyimpan data
  2. , — . (: ), (ex: ).
  3. . (ex: ), (ex: TCP ). .
  4. , . ,
  5. . , . , — . .. .

    , , . .
  6. , .

Informasi tidak diperlukan untuk transcoding dari memori virtual ke fisik dan sebaliknya, setelah restart, informasi ini akan dibuat kembali dengan sendirinya, mungkin dengan cara yang berbeda.

Sedangkan untuk bekerja dengan sistem file. Di antara sistem file, ada yang transaksional. Jika aplikasi membutuhkan perilaku transaksional yang tepat, pelestarian konteks proses harus disinkronkan dengan konfirmasi transaksi sistem file. Di sisi lain, misalnya, untuk merekam log teks, logis untuk menggunakan sistem file biasa, transaksionalitas di sini akan aneh.

Dari semua hal di atas, pertanyaan terbesar disebabkan oleh pelestarian isi memori, volume semua yang lain tidak signifikan dibandingkan dengan ini.
Misalnya, runtimeperpustakaan buffer alokasi memori, meminta mereka dari sistem dalam potongan yang relatif besar, dan mendistribusikan sendiri. Oleh karena itu, membuat / menghapus segmen relatif sedikit.

Tetapi program bekerja terus menerus dengan memori, pada dasarnya itu adalah subsistem memori yang biasanya menjadi hambatan dalam perhitungan. Dan semua yang dapat menyederhanakan hidup kita adalah dukungan perangkat keras untuk bendera halaman yang dimodifikasi. Diharapkan bahwa antara negara menyimpan, tidak terlalu banyak halaman yang dimodifikasi muncul.

Berdasarkan ini, di masa depan kita akan berurusan dengan isi memori.

Menyimpan konten memori


Perilaku yang diinginkan dekat dengan basis data - DBMS dapat “jatuh” kapan saja, tetapi pekerjaan yang dilakukan akan berlanjut sampai komit terakhir. Ini dicapai dengan memelihara log transaksi, masuk ke dalam catatan komit akan mengesahkan semua perubahan yang dibuat untuk transaksi.

Tetapi, karena istilah " memori transaksional " sedang sibuk, kami akan memperkenalkan yang lain - "memori yang tidak dapat dihancurkan".

Dengan begitu saja Anda dapat melihat dua metode yang dengannya memori yang tidak dapat dihancurkan ini dapat diimplementasikan.

Opsi pertama , sebut saja "bersahaja".
Gagasan utamanya adalah bahwa semua data yang diubah dalam suatu transaksi harus ditempatkan dalam RAM. Itu selama operasi, mekanisme swap tidak menyimpan apa pun ke disk, tetapi selama komit, semua halaman yang diubah disimpan ke file swap.

Informasi tentang segmen yang dipilih dan hubungannya dengan tempat di file swap ditulis ke log. Selama operasi, informasi ini diakumulasikan dan dicatat selama komit. Saat memulai ulang, sistem memiliki kemampuan untuk membuat segmen baru. Mekanisme swap akan dapat menarik mereka dan program yang terputus akan secara ajaib menerima datanya.

Namun, dalam mode ini tidak mungkin, misalnya, untuk mengalokasikan array callocth lebih besar dari memori yang tersedia ( mallocth , omong-omong, dimungkinkan). Namun, ini tidak akan menjadi ide yang bagus.

Bahkan jika rezim semacam itu hanya berlaku untuk proses yang telah menyatakan diri mereka "tidak dapat dihancurkan", jumlah memori yang ditempati oleh transaksi saat ini dari semua proses tersebut tidak dapat melebihi yang tersedia secara fisik. Mekanisme swap sebenarnya berhenti bertukar dan berubah menjadi mekanisme untuk menyimpan transaksi terbaru.

Semua ini memaksakan disiplin tertentu pada pengembang aplikasi, dapat menyebabkan beban yang tidak merata pada disk, secara umum, ini tidak seperti yang kita inginkan, tetapi dapat bekerja dalam sistem embedded.

Kelemahan signifikan dari opsi ini adalah bahwa kesalahan fatal selama komit, ketika hanya sebagian halaman yang ditulis, mengarahkan proses yang sesuai ke keadaan tidak stabil, setelah itu akan harus dihentikan.
Ternyata semacam 50% tidak dapat diganggu gugat.

Opsi Dua , "Bayangan"
Untuk bertindak sebagai manajer transaksi, Anda harus menjadi manajer transaksi.

Mari mendefinisikan entitas:

  1. File halaman berisi halaman data, jadi ukurannya adalah kelipatan dari ukuran halaman. Kami mengatakan file, maksud kami bagian itu, karena ukuran tetap meningkatkan stabilitas sistem.
  2. Pengalokasi halaman file halaman . Penting untuk memilih halaman tidak hanya untuk data pengguna, tetapi juga, misalnya, untuk mencatat keadaan pengalokasi itu sendiri. Serta semua yang disebutkan di atas.
  3. . , . , ,
    (= , ).
  4. . —
    • ID
    • ( )
    • ID .

    - TLB, .. .

    ( ) . . , ex: (Buddy Allocator) .

    , . .
  5. . COW (copy on write) . , . COW, - , . .

    — - , “dirty”. .
  6. (). .

    : , .

    . , . . , , . . , ? , .

    , .

    — (= , , , ).


    (=, ). .

    . , . , , , .

    , . , . .

    — . , , , , .
    , , .

    .
  7. . , , — . , ?

    — . , . , . , .. .

    — , SSD ! , SSD ( “” ) .

    , .

    — . , . , . ( ).

    , , , . , , . , , , . , — . .
  8. Checkpoint.

    , , , , . — . , . checkpoint. .

    . . - checkpoint- . .

    , . - .

    checkpoint-. , / .

    -, - /, . , ( ...). .

    . . . , . — , checkpoint.


Sangat disayangkan bahwa tidak ada perangkat penyimpanan yang benar-benar tahan terhadap operasi jangka panjang dalam kondisi ruang. Core ferit tahan terhadap radiasi, tetapi memiliki masalah spesifik mereka sendiri karena banyaknya sambungan yang disolder. Ditambah kapasitas rendah, kecepatan rendah, dan kompleksitas produksi yang tinggi.

Meskipun demikian, Anda harus dapat menulis dan membaca data ini dengan andal.

Calon yang jelas adalah memori flash. Flash pada awalnya tidak terlalu andal karena rendahnya jumlah siklus tulis yang valid, jadi metode khusus dikembangkan untuk mengatasinya .

Sebelumnya disebutkan bahwa tripling digunakan untuk bekerja dengan elemen yang tidak dapat diandalkan, RAID1 sudah cukup di sinikarena jika rekaman gagal karena nilai kontrol, diketahui yang mana dari dua halaman yang ditulis secara salah dan harus ditimpa.

Total


Nah, sekarang kita memiliki keempat huruf dari kata ASAM .

A - atomicity, mencapai
C - konsistensi, ada
I - isolasi, dicapai secara alami. Jika Anda tidak mempertimbangkan kasus memori bersama. Dan saat ini kami tidak mempertimbangkannya.

D -persistence, satu-satunya waktu kami mencoba menipu ketika kami merilis proses setelah komit tanpa menunggu rekaman fisik semua data dalam memorinya ke disk. Dalam kasus terburuk, ini akan menyebabkan kemunduran ke transaksi sebelumnya. Tidak jelas seberapa penting hal ini untuk kinerja dan daya tahan.

PS. Hanya catatan singkat. Kami tidak memiliki mekanisme untuk transaksi rollback, rollback hanya bisa menjadi kesalahan fatal. Secara teknis (tampaknya) mudah untuk menerapkan program transaksi rollback sebagai analog dari longjmp. Tapi ini adalah versi longjmp yang jauh lebih maju sejak itu sepenuhnya memulihkan keadaan internal proses pada saat "setjmp", menghindari kebocoran memori, memungkinkan transisi tidak hanya dari bawah ke atas tumpukan ...

PPS . Mungkin, server OpenLink Virtouso DBMS , tersedia juga sebagai perangkat lunak gratis , dapat dianggap sebagai prototipe dari manajer transaksi .

PPPS . Terima kasih kepada Valery Shunkov (amartologi) dan Anton Bondarev (abondarev) untuk diskusi yang bermakna dan sangat berguna.

PPPPS . Ilustrasi oleh Anna Rusakova .

More articles:


All Articles